-fplugin-arg-dragonegg-enable-gcc-optzns -O3 -fdefault-integer-8 ICE

[llvmbot]

Bugzilla Link	10042
Resolution	FIXED
Resolved on	Feb 10, 2012 06:33
Version	trunk
OS	MacOS X
Attachments	testcase reduced from source/hbuild.f from xplor-nih 2.27
Reporter	LLVM Bugzilla Contributor

Extended Description

While attempting to build xplor-nih with -fplugin-arg-dragonegg-enable-gcc-optzns -O3, I discovered a new type of ICE which can be demonstrated with the attached reduced test case (provide as a tar.gz because of the required fcm files)...

[MacPro:~/debug5] howarth% de-gfortran45 -c hbuild_reduced.f -g -fplugin-arg-dragonegg-enable-gcc-optzns -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore -O3 <array_type 0x14a5482a0
type <integer_type 0x149a3f1f8 character(kind=1) public unsigned string-flag QI
size <integer_cst 0x149a2f758 constant 8>
unit size <integer_cst 0x149a2f780 constant 1>
align 8 symtab 0 alias set 5 canonical type 0x149a3f1f8 precision 8 min <integer_cst 0x149a2f7a8 0> max <integer_cst 0x149a2f7d0 255>
pointer_to_this <pointer_type 0x149a52d20>>
string-flag SI
size <integer_cst 0x149a2f988 type <integer_type 0x149a3f0a8 bit_size_type> constant 32>
unit size <integer_cst 0x149a2f690 type <integer_type 0x149a3f000> constant 4>
align 8 symtab 0 alias set 5 canonical type 0x14a5482a0
domain <integer_type 0x14a5481f8
type <integer_type 0x149a3f498 integer(kind=4) public SI size <integer_cst 0x149a2f988 32> unit size <integer_cst 0x149a2f690 4>
align 32 symtab 0 alias set 8 canonical type 0x149a3f498 precision 32 min <integer_cst 0x149a2f910 -2147483648> max <integer_cst 0x149a2f938 2147483647>
pointer_to_this <pointer_type 0x149a4c3f0>>
SI size <integer_cst 0x149a2f988 32> unit size <integer_cst 0x149a2f690 4>
align 32 symtab 0 alias set -1 canonical type 0x14a5481f8 precision 32 min <integer_cst 0x149a2fed8 1> max <integer_cst 0x14a53d7a8 4>>
pointer_to_this <pointer_type 0x14a608c78>>
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event | Plugins
PLUGIN_FINISH_UNIT | dragonegg
PLUGIN_FINISH | dragonegg
PLUGIN_START_UNIT | dragonegg
hbuild_reduced.f: In function ‘hbuil2_’:
hbuild_reduced.f:4:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

This ICE is suppressed with the addition of -fno-tree-vectorize. FYI, this issue occurs in several other files within xplor-nih.

[llvmbot]

This crash backtraces on x86_64 darwin as...

[MacPro:~/debug5] howarth% gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951
...
(gdb) r hbuild_reduced.f -ffixed-form -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase hbuild_reduced.f -mmacosx-version-min=10.7.0 -mtune=generic -auxbase hbuild_reduced -g -O3 -version -fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -fplugin-arg-dragonegg-enable-gcc-optzns -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore -fintrinsic-modules-path /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o /var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//ccNABEKF.s
...

Versions of loaded plugins:
dragonegg: exported
<array_type 0x141f0c2a0
type <integer_type 0x141d111f8 character(kind=1) public unsigned string-flag QI
size <integer_cst 0x141d01758 constant 8>
unit size <integer_cst 0x141d01780 constant 1>
align 8 symtab 0 alias set 5 canonical type 0x141d111f8 precision 8 min <integer_cst 0x141d017a8 0> max <integer_cst 0x141d017d0 255>
pointer_to_this <pointer_type 0x141d24d20>>
string-flag SI
size <integer_cst 0x141d01988 type <integer_type 0x141d110a8 bit_size_type> constant 32>
unit size <integer_cst 0x141d01690 type <integer_type 0x141d11000> constant 4>
align 8 symtab 0 alias set 5 canonical type 0x141f0c2a0
domain <integer_type 0x141f0c1f8
type <integer_type 0x141d11498 integer(kind=4) public SI size <integer_cst 0x141d01988 32> unit size <integer_cst 0x141d01690 4>
align 32 symtab 0 alias set 8 canonical type 0x141d11498 precision 32 min <integer_cst 0x141d01910 -2147483648> max <integer_cst 0x141d01938 2147483647>
pointer_to_this <pointer_type 0x141d1e3f0>>
SI size <integer_cst 0x141d01988 32> unit size <integer_cst 0x141d01690 4>
align 32 symtab 0 alias set -1 canonical type 0x141f0c1f8 precision 32 min <integer_cst 0x141d01ed8 1> max <integer_cst 0x141f017a8 4>>
pointer_to_this <pointer_type 0x141fccc78>>

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000a
0x000000014280f044 in llvm::DenseMap<llvm::Constant*, llvm::GlobalVariable*, llvm::DenseMapInfollvm::Constant*, llvm::DenseMapInfollvm::GlobalVariable* >::~DenseMap ()
(gdb) bt
#​0 0x000000014280f044 in llvm::DenseMap<llvm::Constant*, llvm::GlobalVariable*, llvm::DenseMapInfollvm::Constant*, llvm::DenseMapInfollvm::GlobalVariable* >::~DenseMap ()
#​1 0x00007fff5fbfdd50 in ?? ()
#​2 0x000000014280a5a6 in ExtractRegisterFromConstantImpl ()
#​3 0x000000014280a7d3 in ExtractRegisterFromConstantImpl ()
#​4 0x000000014280a53c in ExtractRegisterFromConstant ()
#​5 0x000000014282cc15 in TreeToLLVM::EmitRegisterConstant ()
#​6 0x0000000142834e92 in TreeToLLVM::EmitAssignSingleRHS ()
#​7 0x0000000142834224 in TreeToLLVM::EmitAssignRHS ()
#​8 0x0000000142819417 in TreeToLLVM::RenderGIMPLE_ASSIGN ()
#​9 0x00000001428154a2 in TreeToLLVM::EmitBasicBlock ()
#​10 0x000000014281ad8b in TreeToLLVM::EmitFunction ()
#​11 0x0000000142807e50 in emit_current_function ()
#​12 0x00000001428039be in rtl_emit_function ()
#​13 0x0000000100565382 in execute_one_pass (pass=0x142fbd0d8) at ../../gcc-4.5.3/gcc/passes.c:1568
#​14 0x000000010056561d in execute_pass_list (pass=0x142fbd0d8) at ../../gcc-4.5.3/gcc/passes.c:1623
#​15 0x00000001006595c1 in tree_rest_of_compilation (fndecl=0x141f09d00) at ../../gcc-4.5.3/gcc/tree-optimize.c:413
#​16 0x00000001007b4a83 in cgraph_expand_function (node=0x141d0ac30) at ../../gcc-4.5.3/gcc/cgraphunit.c:1555
#​17 0x00000001007b6cf4 in cgraph_optimize () at ../../gcc-4.5.3/gcc/cgraphunit.c:1634
#​18 0x00000001007b71fd in cgraph_finalize_compilation_unit () at ../../gcc-4.5.3/gcc/cgraphunit.c:1103
#​19 0x0000000100505db6 in write_global_declarations () at ../../gcc-4.5.3/gcc/langhooks.c:309
#​20 0x000000010061224e in toplev_main (argc=24, argv=0x7fff5fbfede0) at ../../gcc-4.5.3/gcc/toplev.c:1065
#​21 0x0000000100001594 in start ()
(gdb)

[llvmbot]

This looks like a GCC bug: the optimizers have created a vector of arrays...

[llvmbot]

This looks like a GCC bug: the optimizers have created a vector of arrays...

Do you plan to open a FSF gcc PR for this?

[llvmbot]

Let me poke at it first to understand where it is coming from, and if it has
been fixed in gcc head.

[llvmbot]

This funky vector type is being created by vect_analyze_data_refs in this line:

2068 STMT_VINFO_VECTYPE (stmt_info) =
2069 get_vectype_for_scalar_type (scalar_type);

Here scalar_type is an array type.

[llvmbot]

The same bug is present in gcc mainline (at revision 174743 at least). To
detect it, apply this patch to make_vector_type in tree.c and watch gcc crash
on your testcase. I think the best thing to do is to open a GCC bug for this.

--- tree.c (revision 174743)
+++ tree.c (working copy)
@@ -8968,6 +8968,8 @@
tree t;
hashval_t hashcode = 0;

• if (AGGREGATE_TYPE_P(innertype))
• abort();
  t = make_node (VECTOR_TYPE);
  TREE_TYPE (t) = TYPE_MAIN_VARIANT (innertype);
  SET_TYPE_VECTOR_SUBPARTS (t, nunits);

[llvmbot]

Poking at this a bit more, it looks like maybe GCC doesn't care that this is a
vector of arrays: it seems to be happy as long as the array type can be loaded
and stored as an integer. I'm not yet sure if this is a GCC bug or not...

[llvmbot]

I talked about this on #gcc, and the conclusion was that it seems to be a GCC
bug. I will prepare a small patch that can be applied to GCC to show the
problem (the one in comment 6 is no good).

[llvmbot]

Can you please report this as a GCC bug. The following patch will cause GCC
to crash with an assertion failure if the tree vectorizer tries to form a vector
of arrays.

Index: tree-vect-data-refs.c

--- tree-vect-data-refs.c (revision 174743)
+++ tree-vect-data-refs.c (working copy)
@@ -2734,6 +2734,10 @@
scalar_type = TREE_TYPE (DR_REF (dr));
STMT_VINFO_VECTYPE (stmt_info) =
get_vectype_for_scalar_type (scalar_type);

•  gcc_assert(!STMT_VINFO_VECTYPE (stmt_info) ||
  

•             TREE_CODE (STMT_VINFO_VECTYPE (stmt_info)) != VECTOR_TYPE ||
  

•             TREE_CODE (TREE_TYPE (STMT_VINFO_VECTYPE (stmt_info)))
  

•             != ARRAY_TYPE);
   if (!STMT_VINFO_VECTYPE (stmt_info))
     {
       if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
  

[llvmbot]

Opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49536

[llvmbot]

Opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49536

The fix from gcc trunk...

http://gcc.gnu.org/viewcvs?view=revision&revision=175475

backported onto gcc 4.6.1 doesn't solve the problem with dragonegg svn and the reduced testcase...

[MacPro:~/debug5] howarth% de-gfortran46 -c hbuild_reduced.f -O3 -funroll-loops -g -fplugin-arg-dragonegg-enable-gcc-optzns -fdefault-integer-8 -ffixed-line-length-120 -fno-second-underscore
<addr_expr 0x1438831e0
type <pointer_type 0x14346ae70
type <array_type 0x143449348 type <array_type 0x1434167e0>
type_2 BLK
size <integer_cst 0x141e21960 constant 128>
unit size <integer_cst 0x141e21988 constant 16>
align 8 symtab 0 alias set -1 canonical type 0x143449348 domain <integer_type 0x143449540>
pointer_to_this <pointer_type 0x14346ae70>>
public unsigned DI
size <integer_cst 0x141e217d0 constant 64>
unit size <integer_cst 0x141e217f8 constant 8>
align 64 symtab 0 alias set -1 canonical type 0x14346ae70>

arg 0 <var_decl 0x14344bd20 achy type <array_type 0x143449348>
    addressable used decl_0 BLK file hbuild_reduced.f line 65 col 0 size <integer_cst 0x141e21960 128> unit size <integer_cst 0x141e21988 16>
    align 8 context <function_decl 0x143419900 hbuil2>
    chain <var_decl 0x14344bdc0 bes2hb type <integer_type 0x141e325e8 integer(kind=8)>
        used DI file hbuild_reduced.f line 67 col 0 size <integer_cst 0x141e217d0 64> unit size <integer_cst 0x141e217f8 8>
        align 64 context <function_decl 0x143419900 hbuil2> chain <var_decl 0x14344be60 beshb>>>>

*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event | Plugins
PLUGIN_FINISH_UNIT | dragonegg
PLUGIN_FINISH | dragonegg
PLUGIN_START_UNIT | dragonegg
hbuild_reduced.f: In function ‘hbuil2_’:
hbuild_reduced.f:4:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

[llvmbot]

This is a completely different issue (which I know about already).

[llvmbot]

PS: The issue is gcc-4.6 specific. I expect gcc-4.5 to work if you backport this
patch.

[llvmbot]

I can confirm that the adjusted backport of...

Index: gcc/tree-vect-stmts.c

--- gcc/tree-vect-stmts.c (revision 175535)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -4660,6 +4660,15 @@ get_vectype_for_scalar_type (tree scalar
&& GET_MODE_BITSIZE (inner_mode) != TYPE_PRECISION (scalar_type))
return NULL_TREE;

• /* We shouldn't end up building VECTOR_TYPEs of non-scalar components.

• When the component mode passes the above test simply use a type
  

• corresponding to that mode.  The theory is that any use that
  

• would cause problems with this will disable vectorization anyway.  */
  

• if (!SCALAR_FLOAT_TYPE_P (scalar_type)

•  && !INTEGRAL_TYPE_P (scalar_type)
  

•  && !POINTER_TYPE_P (scalar_type))
  

• scalar_type = lang_hooks.types.type_for_mode (inner_mode, 1);
• /* FORNOW: Only a single vector size per mode (UNITS_PER_SIMD_WORD)
  is expected. */
  nunits = UNITS_PER_SIMD_WORD (inner_mode) / nbytes;

to gcc-4_5-branch solves the dragonegg svn compiler ICE as expected.

[llvmbot]

This was a GCC bug and has been fixed in GCC.