[Bug middle-end/48849] New: [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[Bug middle-end/48849] New: [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

           Summary: [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to
                    build
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


On Linux/ia32, revision 173223 gave

g++ -m32  -O2 -msse2 -mfpmath=sse -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin ...
data_out.cc: In member function 'next_cell':
data_out.cc:689:1: internal compiler error: in get_alias_set, at alias.c:715
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [/tmp/cczXHD8Z.ltrans4.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
specmake[1]: *** [dealII] Error 1

[Bug middle-end/48849] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-05-03 00:57:55 UTC ---
> in get_alias_set, at alias.c:715

Like in my bug 47870.

[Bug middle-end/48849] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com
   Target Milestone|---                         |4.7.0

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2011-05-03 03:03:56 UTC ---
It is caused by revision 173207:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01403.html

[Bug middle-end/48849] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-03 05:49:27 UTC ---
If it is GC related, then perhaps just the fewer stmts make a latent bug
reproduceable.
As switch conversion is early optimization pass, you could try to binary search
in between the *.o files to see on which the switchconv changes trigger it and
with preprocessed source for that I could double check if switchconv is
correct.

I don't have SPEC2k6 easily available for trying to reproduce this myself
though.

[Bug middle-end/48849] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto
                 CC|                            |matz at gcc dot gnu.org

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-03 11:17:07 UTC ---
I think it is more likely caused by Michas type merging changes (ISTR he
was running into a similar issue at some point).

[Bug middle-end/48849] [4.7 Regression] SPEC CPU 2000/2006 failed to build with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.7 Regression] 447.dealII |[4.7 Regression] SPEC CPU
                   |in SPEC CPU 2006 failed to  |2000/2006 failed to build
                   |build                       |with LTO

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-05-19 01:05:37 UTC ---
On Linux/x86-64, revision 20110518 failed to build 32bit 191.fma3d with LTO:

gfortran -m32     -O2 -msse2 -mfpmath=sse -ffast-math -fwhole-program
-flto=jobserver -fuse-linker-plugin  fma3d.o beam_.o include_file_.o penta_.o
segment_set_.o body_force_.o indx_.o periodic_bc_.o sliding_interface_.o
constrained_node_.o layering_.o plate_pair_.o sliding_node_.o contact_node_.o
location_.o platq_.o spot_weld_.o contact_surface_.o lsold_.o platt_.o
spring_.o coord_.o massprop_.o pressure_bc_.o spring_bc_.o damper_.o
material_.o property_.o state_variables_.o damper_bc_.o mean_stress_.o
shared_common_data.o stress_.o displacement_bc_.o membq_.o qa_record_.o
tabulated_function_.o element_set_.o membt_.o relink_scratch_.o tetra_.o
enumerated_sets_.o motion_.o results_.o tied_bc_.o force_.o nodal_point_mass_.o
rigid_body_.o truss_.o force_bc_.o node_.o rigid_body_mass_.o value_.o
gauge1d_.o node_set_.o rigid_wall_bc_.o velocity_ic_.o gauge2d_.o
nonreflecting_bc_.o section_1d_.o gauge3d_.o nrbc_data_.o section_2d_.o
hexah_.o output_.o segment_.o lsold.o damper.o spring.o material_00.o
material_10.o material_11.o material_17.o material_22.o material_25.o
material_32.o material_33.o material_34a.o material_36.o material_38.o
material_dm.o material_sp.o sort.o pdb.o beam.o membq.o membt.o penta.o tetra.o
hexah.o platq.o truss.o platt.o fma1.o getirv.o relink.o output.o fma2.o
partition.o strain.o slide.o     -o fma3d
...
In file included from fma1.f90:4220:0,
                 from :102:
getirv.f90: In function 'rcrdrd':
getirv.f90:466:0: internal compiler error: in get_alias_set, at alias.c:715
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [/tmp/cc1acnOL.ltrans21.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
specmake[3]: *** [fma3d] Error 1

[Bug middle-end/48849] [4.7 Regression] SPEC CPU 2000/2006 failed to build with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.05.19 08:49:11
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-19 08:49:11 UTC ---
Btw, I looked into similar ICEs I get on x86_64 SPEC2k6 and the issue is that
LTO TYPE_CANONICAL merging behaves different than the middle-end when it
constructs new pointer types (that is what I was looking at, similar issues
apply to vector and complex and array types I think).  That is, for the
middle-end the canonical type of a pointer type is a pointer to the canonical
pointed-to type while LTO TYPE_CANONICAL building does something different.

Now, a simple patch like

Index: gcc/gimple.c
===================================================================
--- gcc/gimple.c        (revision 173724)
+++ gcc/gimple.c        (working copy)
@@ -4830,6 +4830,25 @@ gimple_register_canonical_type (tree t)
   if (TYPE_MAIN_VARIANT (t) != t)
     gimple_register_canonical_type (TYPE_MAIN_VARIANT (t));

+  /* For pointer and reference types do as the middle-end does - the
+     canonical type is a pointer to the canonical pointed-to type.  */
+  if (TREE_CODE (t) == POINTER_TYPE)
+    {
+      TYPE_CANONICAL (t)
+       = build_pointer_type_for_mode
+           (gimple_register_canonical_type (TREE_TYPE (t)),
+            TYPE_MODE (t), TYPE_REF_CAN_ALIAS_ALL (t));
+      return TYPE_CANONICAL (t);
+    }
+  else if (TREE_CODE (t) == REFERENCE_TYPE)
+    {
+      TYPE_CANONICAL (t)
+       = build_reference_type_for_mode
+           (gimple_register_canonical_type (TREE_TYPE (t)),
+            TYPE_MODE (t), TYPE_REF_CAN_ALIAS_ALL (t));
+      return TYPE_CANONICAL (t);
+    }
+
   if (gimple_canonical_types == NULL)
     gimple_canonical_types = htab_create_ggc (16381,
gimple_canonical_type_hash,
                                              gimple_canonical_type_eq, 0);

that I tested after analyzing the issue doesn't work as the middle-end
pointer-type building depends on properly setup TYPE_POINTER_TO lists
which we are only about to construct when re-building canonical types.

Anyway, I was working on this but got distracted.

[Bug middle-end/48849] [4.7 Regression] SPEC CPU 2000/2006 failed to build with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-20 09:35:47 UTC ---
Author: rguenth
Date: Fri May 20 09:35:44 2011
New Revision: 173939

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173939
Log:
2011-05-20  Richard Guenther  <rguenther@suse.de>

    PR middle-end/48849
    * gimple.c (gimple_register_canonical_type): Compute TYPE_CANONICAL
    of pointer types the same way the middle-end does.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c

[Bug middle-end/48849] [4.7 Regression] SPEC CPU 2000/2006 failed to build with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Depends on|                            |49078
         Resolution|                            |FIXED

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-20 15:12:18 UTC ---
Fixed but caused PR49078.