[Bug tree-optimization/62071] New: [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[Bug tree-optimization/62071] New: [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[trippels at gcc dot gnu.org]

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

            Bug ID: 62071
           Summary: [4.10 Regression] ICE: in before_dom_children, at
                    tree-ssa-pre.c:4411
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

During Firefox -flto libxul link I get:

/var/tmp/mozilla-central/dom/events/TextComposition.cpp: In member function
‘_ZN7mozilla15TextComposition26CompositionEventDispatcher3RunEv.part.96’:
/var/tmp/mozilla-central/dom/events/TextComposition.cpp:217:0: internal
compiler error: in before_dom_children, at tree-ssa-pre.c:4411
 TextComposition::CompositionEventDispatcher::Run()
 ^
0xa7760b eliminate_dom_walker::before_dom_children(basic_block_def*)
        ../../gcc/gcc/tree-ssa-pre.c:4411
0xdfd667 dom_walker::walk(basic_block_def*)
        ../../gcc/gcc/domwalk.c:177
0xa74402 eliminate
        ../../gcc/gcc/tree-ssa-pre.c:4526
0xa74645 execute
        ../../gcc/gcc/tree-ssa-pre.c:4941
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[6]: *** [/tmp/cceU40zS.ltrans9.ltrans.o] Error 1
make[6]: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: fatal error

Started with r213739.

I will try to reduce this next week.
>From gcc-bugs-return-458067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 08 20:55:50 2014
Return-Path: <gcc-bugs-return-458067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9307 invoked by alias); 8 Aug 2014 20:55:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9110 invoked by uid 48); 8 Aug 2014 20:55:45 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?
Date: Fri, 08 Aug 2014 20:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcj
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62068-4-mdZaeZk7e8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62068-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62068-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg00564.txt.bz2
Content-length: 141

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb068

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
Please reread comment#1.

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Fixed by r213781.

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Honza, your comment belongs to PR62091. 
This is the wrong bug.

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[jason at redhat dot com]

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

--- Comment #5 from Jason Merrill <jason at redhat dot com> ---
On 08/14/2014 02:10 PM, Jan Hubicka wrote:
> I wonder what we should do with both external and comdat here.  Jason, can we devirtualize?

No, we're setting comdat now to avoid devirtualization, because we can't 
be confident that we'll be able to refer to the definition where it gets 
emitted.

> The constructor is keyed to other compilation unit here, but we are provided with a body
> that we will never use (modulo the tree-ssa-pre bug that brings the reference into code).

Hmm, we might consider overriding DECL_EXTERNAL so that there's a 
definition available for devirtualization.

Jason

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
> On 08/14/2014 02:10 PM, Jan Hubicka wrote:
> >I wonder what we should do with both external and comdat here.  Jason, can we devirtualize?
> 
> No, we're setting comdat now to avoid devirtualization, because we
> can't be confident that we'll be able to refer to the definition
> where it gets emitted.

We had issues where function body was not produced because it is not reachable
by the frontend's definition and it would be comdat otherwise. The case of
inline function whose out of line body is keyed to another unit seems bit
different...
> 
> >The constructor is keyed to other compilation unit here, but we are provided with a body
> >that we will never use (modulo the tree-ssa-pre bug that brings the reference into code).
> 
> Hmm, we might consider overriding DECL_EXTERNAL so that there's a
> definition available for devirtualization.

I can always implement logic to use it only when it is inlined, but that will
probably drag
in references to other symbols belonging to the class...

Honza

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[jason at redhat dot com]

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

--- Comment #7 from Jason Merrill <jason at redhat dot com> ---
On 08/14/2014 07:13 PM, Jan Hubicka wrote:
>> On 08/14/2014 02:10 PM, Jan Hubicka wrote:
>>> I wonder what we should do with both external and comdat here.  Jason, can we devirtualize?
>>
>> No, we're setting comdat now to avoid devirtualization, because we
>> can't be confident that we'll be able to refer to the definition
>> where it gets emitted.
>
> We had issues where function body was not produced because it is not reachable
> by the frontend's definition and it would be comdat otherwise. The case of
> inline function whose out of line body is keyed to another unit seems bit
> different...

It doesn't seem that different to me.  In both cases we don't have a 
local definition to refer to.

>>> The constructor is keyed to other compilation unit here, but we are provided with a body
>>> that we will never use (modulo the tree-ssa-pre bug that brings the reference into code).
>>
>> Hmm, we might consider overriding DECL_EXTERNAL so that there's a
>> definition available for devirtualization.
>
> I can always implement logic to use it only when it is inlined, but that will probably drag
> in references to other symbols belonging to the class...

I'm not too concerned about that; users should expect an inline function 
to be inlined.

Jason

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
> On 08/14/2014 07:13 PM, Jan Hubicka wrote:
> >>On 08/14/2014 02:10 PM, Jan Hubicka wrote:
> >>>I wonder what we should do with both external and comdat here.  Jason, can we devirtualize?
> >>
> >>No, we're setting comdat now to avoid devirtualization, because we
> >>can't be confident that we'll be able to refer to the definition
> >>where it gets emitted.
> >
> >We had issues where function body was not produced because it is not reachable
> >by the frontend's definition and it would be comdat otherwise. The case of
> >inline function whose out of line body is keyed to another unit seems bit
> >different...
> 
> It doesn't seem that different to me.  In both cases we don't have a
> local definition to refer to.

I think the difference is that in one case we break ABI (by referring to the
symbol without providing a comdat body).

In the other case we just require user to link with classes he declares in
headers. So far I was always able to convince users to do the second.  We won't
devirtualize when explicit hidden attribute is present on the function body.
> 
> >>>The constructor is keyed to other compilation unit here, but we are provided with a body
> >>>that we will never use (modulo the tree-ssa-pre bug that brings the reference into code).
> >>
> >>Hmm, we might consider overriding DECL_EXTERNAL so that there's a
> >>definition available for devirtualization.
> >
> >I can always implement logic to use it only when it is inlined, but that will probably drag
> >in references to other symbols belonging to the class...
> 
> I'm not too concerned about that; users should expect an inline
> function to be inlined.

I guess I will need to add the necessary infrastructure then - so far we make
no difference
in between referring symbol and inlining body becuase before inlining we always
temporarily
produce the direct reference.

Honza

[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> ---
> >>>The constructor is keyed to other compilation unit here, but we are provided with a body
> >>>that we will never use (modulo the tree-ssa-pre bug that brings the reference into code).
> >>
> >>Hmm, we might consider overriding DECL_EXTERNAL so that there's a
> >>definition available for devirtualization.
> >
> >I can always implement logic to use it only when it is inlined, but that will probably drag
> >in references to other symbols belonging to the class...
> 
> I'm not too concerned about that; users should expect an inline
> function to be inlined.

Thiking about this - can't we make these just DECL_COMDAT?  If it is safe to
inline them, it is also safe to introduce COMDAT copy of the body if we
introduce the reference to it. Becaue the method is keyed, it will be overriden
by non-weak in the case user links with the implementation. If he doesn't then
the weak copy is no worse (reference wise) than inline copy...

Honza