[Bug lto/48065] New: LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[Bug lto/48065] New: LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

           Summary: LTO: assertion failed in optimize_inline_calls, at
                    tree-inline.c:4246
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com


Created attachment 23618
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23618
testcase

In file included from :0:0:
main.c: In function 'main':
main.c:3:5: internal compiler error: in optimize_inline_calls, at
tree-inline.c:4246

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-03-10 20:00:27 UTC ---
Created attachment 23619
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23619
backtrace

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-checking, lto
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.11 10:03:26
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-11 10:03:26 UTC ---
Hum, this checking that triggers is somewhat bogus as at least with LTO
we end up rejecting some inlines late in expand_call_inline.

With the inliner reorg we should try to avoid this more consistently.

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-07-14 23:14:33 UTC ---
I can't reproduce it now.

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

--- Comment #4 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-07-15 00:01:49 UTC ---
Still in GCC 4.6 (when checking is turned on).

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-03 16:33:29 UTC ---
Hmm, rejecting inlines late at ltrans stage really is problem as discussed
earlier - we make assumptions on the optimizations of constant parameters and
we won't export offline function

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-03 16:37:00 UTC ---
Hmm, rejecting inlines late at ltrans stage really is problem as discussed
earlier - we make assumptions on the optimizations of constant parameters and
we won't export offline copy in partitioning so it may lead to undefined
reference.  How do you expect this to work? Where we do the refusal?
I do not see any code there.
I would really preffer inlining to work (and produce wrong code in undefined
cases perhaps with warning) rather than giving up on the inline plan.  If this
is not possible to implement, we can materialize a clone with the expected
constant propagated and redirect call there, but it is tricky to implement,
too.

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-03 16:40:48 UTC ---
We definitely should be able to make it work.  We can simply inline
abort () ;)

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-04 10:51:30 UTC ---
I think we don't fail late now, at least not in expand_call_inline (unless
inline_failed is re-computed at LTRANS stage).

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> 2013-01-04 21:26:04 UTC ---
> I think we don't fail late now, at least not in expand_call_inline (unless
> inline_failed is re-computed at LTRANS stage).
Yes, i think we simply produce invalid gimple and type later on errneous
conversion.
At least we did so last time I hit the issue with Mozilla ;)

Honza

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065

Arseny Solokha <asolokha at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asolokha at gmx dot com

--- Comment #10 from Arseny Solokha <asolokha at gmx dot com> ---
Is it still an issue?

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Let's assume it's fixed.  The code changed quite a bit meanwhile.