[Bug lto/51105] New: [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[Bug lto/51105] New: [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[dominiq at lps dot ens.fr]

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

             Bug #: 51105
           Summary: [4.7 Regression] FAIL:
                    gcc.c-torture/execute/920501-1.c compilation,  -O2
                    -flto -flto-partition=none
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: hjl.tools@gmail.com, rguenther@suse.de


Between revisions 181189 (OK) and 181208 (see
http://gcc.gnu.org/ml/gcc-regression/2011-11/msg00230.html : r181205?), the
test gcc.c-torture/execute/920501-1.c compiled with '-O2 -flto
-flto-partition=none' has started to give an ICE:

lto1: internal compiler error: in can_inline_edge_p, at ipa-inline.c:353

This corresponds to the gcc_checking_assert for

/* In -flto-partition=none mode we really keep things out of
   sync because call_stmt_cannot_inline_p is set at cgraph
   merging when function bodies are not there yet.  */
|| (in_lto_p && !gimple_call_cannot_inline_p (e->call_stmt)));

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-11-14 18:25:23 UTC ---
*** Bug 51123 has been marked as a duplicate of this bug. ***

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-14
     Ever Confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-11-14 18:28:42 UTC ---
If this pr has a duplicate, I think it is confirmed.

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

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

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-11-15 08:34:33 UTC ---
Please fill in (host and) target fields.
I can confirm a wider range for cris-elf cross from x86_64-*-linux*; same
behavior and log message (FWIW due to breakage in the tree my observed range is
wider, 181187:181254).
I have no doubt the regression occurred in 181189:181208 as per the archive
link; I'll bisect from that.

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-11-15 14:19:40 UTC ---
> Please fill in (host and) target fields.

What for? AFAICT the field should be *-*-* with lto enabled.

If I fill a bug report, it is because I see it on one of the machines I use:
x86_64-apple-darwin10 (181046:181258) or powerpc-apple-darwin9 (181105:181301).
Then I check the bots' results at
http://gcc.gnu.org/ml/gcc-testresults/2011-11/ to see if the failure is
darwin/ppc specific. In the later case I fill the triplet, but I don't if the
failure appears generic as this one.

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-11-16 00:11:37 UTC ---
(In reply to comment #4)
> > Please fill in (host and) target fields.
> What for? AFAICT the field should be *-*-* with lto enabled.

A *-*-* would certainly be better than empty, which just says that someone
forgot or didn't know what to write, which is usually the case when that field
is empty.

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-11-16 10:21:38 UTC ---
(In reply to comment #3)
> I have no doubt the regression occurred in 181189:181208 as per the archive
> link; I'll bisect from that.

It's r181205:181206 (r181205 was a build failure, the next was a partly
revert), but you knew that already didn't you Richi?  ;-] (Being already
CC:ed.)

[Bug lto/51105] [4.7 Regression] FAIL: gcc.c-torture/execute/920501-1.c compilation, -O2 -flto -flto-partition=none

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dnovillo at gcc dot gnu.org
         Resolution|                            |FIXED

--- Comment #7 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-12-03 01:59:05 UTC ---
This was fixed for cris-elf in the revision range r181888:181895.
The reports http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00098.html and
http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00111.html narrow down the
range to r181892:181894 which according to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00107.html was intended, so I'm
closing this PR.