public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409
@ 2011-04-07 23:21 hubicka at gcc dot gnu.org
  2011-04-07 23:25 ` [Bug lto/48508] " hubicka at gcc dot gnu.org
                   ` (16 more replies)
  0 siblings, 17 replies; 18+ messages in thread
From: hubicka at gcc dot gnu.org @ 2011-04-07 23:21 UTC (permalink / raw)
  To: gcc-bugs

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

           Summary: ICE in output_die, at dwarf2out.c:11409
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


/abuild/jh/trunk-install/bin/g++ -flto=25   ~/jsatom.ii ~/jscntxt.ii ~/jsgc.ii
~/jsinterp.ii ~/jsinvoke.ii ~/jsiter.ii  -r -nostdlib  -g -O3

leads eventually to

lto1: internal compiler error: in output_die, at dwarf2out.c:11409
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

It seems that all the files are needed to reproduce the ICE.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
@ 2011-04-07 23:25 ` hubicka at gcc dot gnu.org
  2011-04-08 10:09 ` rguenth at gcc dot gnu.org
                   ` (15 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu.org @ 2011-04-07 23:25 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-07 23:25:43 UTC ---
Created attachment 23922
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23922
testcase


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
  2011-04-07 23:25 ` [Bug lto/48508] " hubicka at gcc dot gnu.org
@ 2011-04-08 10:09 ` rguenth at gcc dot gnu.org
  2011-04-08 15:17 ` hubicka at gcc dot gnu.org
                   ` (14 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-04-08 10:09 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-08 10:09:15 UTC ---
I think I've seen this before ...


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
  2011-04-07 23:25 ` [Bug lto/48508] " hubicka at gcc dot gnu.org
  2011-04-08 10:09 ` rguenth at gcc dot gnu.org
@ 2011-04-08 15:17 ` hubicka at gcc dot gnu.org
  2011-04-22  9:33 ` hubicka at gcc dot gnu.org
                   ` (13 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu.org @ 2011-04-08 15:17 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-08 15:17:33 UTC ---
To me all those debugging ICEs seems alike, but bugzilla don't seem to find any
other output_die ICE. I didn't had chance to look deeper into what is wrong,
but unlike most of other cases we crash while outputting dwarf, not while
constructing it.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2011-04-08 15:17 ` hubicka at gcc dot gnu.org
@ 2011-04-22  9:33 ` hubicka at gcc dot gnu.org
  2011-05-26 11:57 ` rguenth at gcc dot gnu.org
                   ` (12 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu.org @ 2011-04-22  9:33 UTC (permalink / raw)
  To: gcc-bugs

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.04.22 09:32:12
     Ever Confirmed|0                           |1

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-22 09:32:12 UTC ---
Still reproduce at current mainline.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2011-04-22  9:33 ` hubicka at gcc dot gnu.org
@ 2011-05-26 11:57 ` rguenth at gcc dot gnu.org
  2011-11-06 19:01 ` josh.m.conner at gmail dot com
                   ` (11 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-05-26 11:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-26 11:51:37 UTC ---
Created attachment 24363
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24363
reduced testcase

Reduced to two files, delta-reduced, independend on file order

> g++ -g -flto -O2 -r -nostdlib jsinterp.3.ii jsatom.3.ii
lto1: internal compiler error: in output_die, at dwarf2out.c:11622
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2011-05-26 11:57 ` rguenth at gcc dot gnu.org
@ 2011-11-06 19:01 ` josh.m.conner at gmail dot com
  2011-12-09 13:50 ` rguenth at gcc dot gnu.org
                   ` (10 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: josh.m.conner at gmail dot com @ 2011-11-06 19:01 UTC (permalink / raw)
  To: gcc-bugs

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

Joshua Conner <josh.m.conner at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josh.m.conner at gmail dot
                   |                            |com

--- Comment #6 from Joshua Conner <josh.m.conner at gmail dot com> 2011-11-06 19:01:26 UTC ---
I ran into this bug building SPEC2k for ARM (176.gcc) w/LTO, and have done some
investigation.

In the provided test case, during inlining we generate an abstract function die
for js_InternNonIntElementIdSlow (and the inlined instance with an
abstract_origin referring to the abstract function die).

Later, when we are generating the debug information for the non-slow version of
the function, js_InternNonIntElementId, we process the declaration that appears
inside that function:

  extern bool js_InternNonIntElementIdSlow (JSContext *, JSObject *,
                                            const js::Value &, long int *,
                                            js::Value *);

We attempt to generate a die for this, and in doing so when looking up the decl
using lookup_decl_die, we are returned the abstract instance of the "...Slow"
function.  We then attempt to re-define this die by clearing out the parameters
from old instance and re-using it (see the code that follows this comment in
gen_subprogram_die):

      /* If the definition comes from the same place as the declaration,
         maybe use the old DIE.  We always want the DIE for this function
         that has the *_pc attributes to be under comp_unit_die so the
         debugger can find it.  We also need to do this for abstract
         instances of inlines, since the spec requires the out-of-line copy
         to have the same parent.  For local class methods, this doesn't
         apply; we just use the old DIE.  */

Once we clear out the parameters, then the abstract_origin parameters in our
original inlined instance now point to unreachable/unallocated dies, triggering
the assertion failure.

It's not clear to me what the fix is, so I could use some insight into what
cases this code is supposed to handle.  From reading the comments and code, it
appears that we're trying to catch a case where we have a declaration followed
by a definition?  So, it's possible that we should recognize that we don't have
a definition here, just a declaration.  Alternatively (or in addition), should
we recognize that we are dealing with an abstract declaration and not try to
re-use it, since doing so will break any references that were almost certainly
generated?


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2011-11-06 19:01 ` josh.m.conner at gmail dot com
@ 2011-12-09 13:50 ` rguenth at gcc dot gnu.org
  2011-12-09 18:27 ` jason at gcc dot gnu.org
                   ` (9 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-09 13:50 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-09 13:17:47 UTC ---
(gdb) call debug_dwarf_die (die)
DIE  459: DW_TAG_formal_parameter (0x7ffff5befdc0)
  abbrev id: 22 offset: 459 mark: 1
  DW_AT_abstract_origin: die -> 0 (0x7ffff5bef730)
  DW_AT_location: location descriptor

(gdb) call debug_dwarf_die (0x7ffff5bef730)
DIE    0: DW_TAG_formal_parameter (0x7ffff5bef730)
  abbrev id: 0 offset: 0 mark: 2
  DW_AT_name: "cx"
  DW_AT_decl_file: "jsatom.3.ii" (1)
  DW_AT_decl_line: 58
  DW_AT_type: die -> 287 (0x7ffff5bebc30)

So the question is why was that DIE not output.  The answer is possibly
because dwarf2out.c would do so only when a proper debug hook is called
from the frontend.

The DIE get's generated via

#0  gen_formal_parameter_die (node=0x7ffff5b6f5d8, origin=0x0, 
    emit_name_p=1 '\001', context_die=0x7ffff5bf0690)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16703
#1  0x000000000062e8b6 in gen_decl_die (decl=0x7ffff5b6f5d8, origin=0x0, 
    context_die=0x7ffff5bf0690)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19576
#2  0x0000000000624ac7 in gen_subprogram_die (decl=0x7ffff5b70d00, 
    context_die=0x7ffff5bec410)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:17496
#3  0x000000000062dfac in gen_decl_die (decl=0x7ffff5b70d00, origin=0x0, 
    context_die=0x7ffff5bec410)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19489
#4  0x000000000062f48e in dwarf2out_decl (decl=0x7ffff5b70d00)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19863
#5  0x000000000062321a in dwarf2out_abstract_function (decl=0x7ffff5b70d00)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16969
#6  0x000000000057316b in gimple_expand_cfg ()
    at /space/rguenther/src/svn/trunk/gcc/cfgexpand.c:4654

so it was created up-front to be used by inline instances.  But for some
reason we do not mark it for output even though it ends up being used.

We are creating a DIE for the same parameter again, via

#0  gen_formal_parameter_die (node=0x7ffff5b6f5d8, origin=0x0, 
    emit_name_p=1 '\001', context_die=0x7ffff5bf0cd0)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:16703
#1  0x000000000062e8b6 in gen_decl_die (decl=0x7ffff5b6f5d8, origin=0x0, 
    context_die=0x7ffff5bf0cd0)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19576
#2  0x0000000000624ac7 in gen_subprogram_die (decl=0x7ffff5b70d00, 
    context_die=0x7ffff5bec410)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:17496
#3  0x000000000062dfac in gen_decl_die (decl=0x7ffff5b70d00, origin=0x0, 
    context_die=0x7ffff5bec410)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19489
#4  0x000000000062f48e in dwarf2out_decl (decl=0x7ffff5b70d00)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19863
#5  0x000000000062f4c9 in dwarf2out_function_decl (decl=0x7ffff5b70d00)
    at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19871
#6  0x00000000006a6b89 in rest_of_handle_final ()
    at /space/rguenther/src/svn/trunk/gcc/final.c:4349

interestingly the 2nd one (not found by lookup_decl_die) is the one
that refers to the DIE in question.

Guarding it like

Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 182154)
+++ dwarf2out.c (working copy)
@@ -19868,7 +19868,8 @@ dwarf2out_decl (tree decl)
 static void
 dwarf2out_function_decl (tree decl)
 {
-  dwarf2out_decl (decl);
+  if (!lookup_decl_die (decl))
+    dwarf2out_decl (decl);
   call_arg_locations = NULL;
   call_arg_loc_last = NULL;
   call_site_count = -1;

fixes the ICE.

Now the question is what guarantees that this does not happen?  Should we
be able to assert like

Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 182154)
+++ dwarf2out.c (working copy)
@@ -5171,6 +5171,7 @@ equate_decl_number_to_die (tree decl, dw
   void **slot;

   slot = htab_find_slot_with_hash (decl_die_table, decl, decl_id, INSERT);
+  gcc_assert (!*slot || *slot == decl_die);
   *slot = decl_die;
   decl_die->decl_id = decl_id;
 }

?  That trivially asserts already at compile-time, without -flto.

Or is this an odering issue somehow and the two DIEs should have been
created in the opposite order?  Or should the DIE reference have been
created inbetween the two calls?

I realize this has more questions than answers ... :/


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2011-12-09 13:50 ` rguenth at gcc dot gnu.org
@ 2011-12-09 18:27 ` jason at gcc dot gnu.org
  2011-12-09 20:09 ` jason at gcc dot gnu.org
                   ` (8 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: jason at gcc dot gnu.org @ 2011-12-09 18:27 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> 2011-12-09 18:22:38 UTC ---
We shouldn't be emitting anything for that nested function declaration in the
concrete instance of the inlined function, and we don't when compiling without
LTO.  In normal compilation the block extern doesn't show up in BLOCK_VARS of
the inlined block, but rather in BLOCK_NONLOCALIZED_VARS, so we pass down NULL
for decl to gen_decl_die, so it doesn't call gen_subprogram_die.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2011-12-09 18:27 ` jason at gcc dot gnu.org
@ 2011-12-09 20:09 ` jason at gcc dot gnu.org
  2011-12-12 12:41 ` rguenth at gcc dot gnu.org
                   ` (7 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: jason at gcc dot gnu.org @ 2011-12-09 20:09 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2011-12-09 20:04:44 UTC ---
Created attachment 26035
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26035
Patch to avoid generating abstract function for block extern

While I was looking at what we do in normal compilation I noticed that do call
dwarf2out_abstract_function for an inlined block extern, which seems wrong;
this patch fixes that, and I thought it could go in along with the fix for this
bug.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (8 preceding siblings ...)
  2011-12-09 20:09 ` jason at gcc dot gnu.org
@ 2011-12-12 12:41 ` rguenth at gcc dot gnu.org
  2011-12-12 12:46 ` rguenth at gcc dot gnu.org
                   ` (6 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-12 12:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-12 12:39:04 UTC ---
(In reply to comment #8)
> We shouldn't be emitting anything for that nested function declaration in the
> concrete instance of the inlined function, and we don't when compiling without
> LTO.  In normal compilation the block extern doesn't show up in BLOCK_VARS of
> the inlined block, but rather in BLOCK_NONLOCALIZED_VARS, so we pass down NULL
> for decl to gen_decl_die, so it doesn't call gen_subprogram_die.

It's also in BLOCK_NONLOCALIZED_VARS in the lto case.  Note that the
creation of the dup doesn't go through decls_for_scope at all.

But what definitely happens is that we "screw up" BLOCK trees in a major
way with LTO (see PR47799 for some details).  Not sure if that is related,
though (as, -fno-early-inlining does not help for this bug).  It does
sound related though as one copy is emitted via the dwarf2out_abstract_function
hook.

It is still a mystery how we avoid

gimple_expand_cfg (void)
{
...
  /* We are now committed to emitting code for this function.  Do any
     preparation, such as emitting abstract debug info for the inline
     before it gets mangled by optimization.  */
  if (cgraph_function_possibly_inlined_p (current_function_decl))
    (*debug_hooks->outlining_inline_function) (current_function_decl);
...

and

rest_of_handle_final (void)
{
...
  /* Note that for those inline functions where we don't initially
     know for certain that we will be generating an out-of-line copy,
     the first invocation of this routine (rest_of_compilation) will
     skip over this code by doing a `goto exit_rest_of_compilation;'.
     Later on, wrapup_global_declarations will (indirectly) call
     rest_of_compilation again for those inline functions that need
     to have out-of-line copies generated.  During that call, we
     *will* be routed past here.  */

  timevar_push (TV_SYMOUT);
  if (!DECL_IGNORED_P (current_function_decl))
    debug_hooks->function_decl (current_function_decl);
  timevar_pop (TV_SYMOUT);

from clashing with respect to the decl_die_table without LTO.  So my
theory still stands that somehow this clash is forseen but we make
sure to create all DIE references "in proper order" so that this doesn't
matter?  But we do not follow that "proper order" with LTO.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (9 preceding siblings ...)
  2011-12-12 12:41 ` rguenth at gcc dot gnu.org
@ 2011-12-12 12:46 ` rguenth at gcc dot gnu.org
  2011-12-14 14:34 ` rguenth at gcc dot gnu.org
                   ` (5 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-12 12:46 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-12 12:40:42 UTC ---
Created attachment 26056
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26056
manually reduced testcase


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (10 preceding siblings ...)
  2011-12-12 12:46 ` rguenth at gcc dot gnu.org
@ 2011-12-14 14:34 ` rguenth at gcc dot gnu.org
  2011-12-14 15:14 ` rguenth at gcc dot gnu.org
                   ` (4 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-14 14:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-14 14:33:27 UTC ---
Even more reduced, fails with

> ./g++ -B. -g -O -r -nostdlib 1.ii 2.ii -flto -finline-small-functions
lto1: internal compiler error: in output_die, at dwarf2out.c:8401

1.ii
----
class Value;
bool js_ValueToAtom(const Value &v);
void
js_InternNonIntElementIdSlow(const Value &idval)
{
  js_ValueToAtom(idval);
} 

2.ii
----
class Value;
void
js_InternNonIntElementId(const Value &idval)
{
  extern void js_InternNonIntElementIdSlow(const Value &);
  js_InternNonIntElementIdSlow(idval);
}
void
Interpret(const Value &idval_)
{
  js_InternNonIntElementId(idval_);
}

Appearantly it is required that js_InternNonIntElementId is inlined
eary while js_InternNonIntElementIdSlow is inlined two times at IPA
time, both into js_InternNonIntElementId and Interpret.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (11 preceding siblings ...)
  2011-12-14 14:34 ` rguenth at gcc dot gnu.org
@ 2011-12-14 15:14 ` rguenth at gcc dot gnu.org
  2011-12-14 15:32 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-14 15:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-14 15:00:23 UTC ---
Even more reduced:

void __attribute__((externally_visible))
foo (int i)
{
}

-----

static void
bar (void)
{
  extern void foo (int);
  foo (0);
}
int main()
{
  bar ();
}

which also links ok when it works.  Does not fail with C but only C++
but is valid source for both.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (12 preceding siblings ...)
  2011-12-14 15:14 ` rguenth at gcc dot gnu.org
@ 2011-12-14 15:32 ` rguenth at gcc dot gnu.org
  2011-12-14 16:04 ` rguenth at gcc dot gnu.org
                   ` (2 subsequent siblings)
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-14 15:32 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-14 15:23:18 UTC ---
Hm.  It seems that unlike the C FE the C++ FE emits new global fndecls for
each block-local extern it encounters.  So, for

extern void foo (int);
static void
bar (void)
{
  extern void foo (int);
  foo (0);
}
int main()
{
  extern void foo (int);
  bar ();
}

we'll have three FUNCTION_DECLs for the global foo, two queued in
BLOCK_VARS but with global context (the C FE would have a DECL_CONTEXT
of the enclosing function declaration, bar and main here).  So the C++
frontend will be still susceptible to PR48437, those local decls entering
the decl merging process.

Which means that if we fix this bug in another way this bug is fixed
as well!  One idea is to simply never treat trees that we output
when following TREE_CHAIN as indexable.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (13 preceding siblings ...)
  2011-12-14 15:32 ` rguenth at gcc dot gnu.org
@ 2011-12-14 16:04 ` rguenth at gcc dot gnu.org
  2011-12-15  9:46 ` rguenth at gcc dot gnu.org
  2011-12-15  9:52 ` rguenth at gcc dot gnu.org
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-14 16:04 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-14 15:52:59 UTC ---
Bah, that doesn't work for local statics!  Let's see if the following works
(though it looks a bit too non-localized given the various callers to
streamer_write_chain - the FIELD_DECL chain is especially susceptible
considering C++ class methods).


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (14 preceding siblings ...)
  2011-12-14 16:04 ` rguenth at gcc dot gnu.org
@ 2011-12-15  9:46 ` rguenth at gcc dot gnu.org
  2011-12-15  9:52 ` rguenth at gcc dot gnu.org
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-15  9:46 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-15 09:44:17 UTC ---
Author: rguenth
Date: Thu Dec 15 09:44:11 2011
New Revision: 182358

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182358
Log:
2012-12-15  Richard Guenther  <rguenther@suse.de>

    Revert
    PR lto/48437
    * lto-streamer-out.c (tree_is_indexable): Exclude block-local
    extern declarations.

    PR lto/48508
    PR lto/48437
    * tree-streamer-out.c (streamer_write_chain): Stream DECL_EXTERNAL
    VAR_DECLs and FUNCTION_DECLs locally.

    * g++.dg/lto/pr48508-1_0.C: New testcase.
    * g++.dg/lto/pr48508-1_1.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/lto/pr48508-1_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr48508-1_1.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-streamer-out.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-streamer-out.c


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [Bug lto/48508] ICE in output_die, at dwarf2out.c:11409
  2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
                   ` (15 preceding siblings ...)
  2011-12-15  9:46 ` rguenth at gcc dot gnu.org
@ 2011-12-15  9:52 ` rguenth at gcc dot gnu.org
  16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-15  9:52 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-15 09:49:36 UTC ---
Fixed.


^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2011-12-15  9:51 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-07 23:21 [Bug lto/48508] New: ICE in output_die, at dwarf2out.c:11409 hubicka at gcc dot gnu.org
2011-04-07 23:25 ` [Bug lto/48508] " hubicka at gcc dot gnu.org
2011-04-08 10:09 ` rguenth at gcc dot gnu.org
2011-04-08 15:17 ` hubicka at gcc dot gnu.org
2011-04-22  9:33 ` hubicka at gcc dot gnu.org
2011-05-26 11:57 ` rguenth at gcc dot gnu.org
2011-11-06 19:01 ` josh.m.conner at gmail dot com
2011-12-09 13:50 ` rguenth at gcc dot gnu.org
2011-12-09 18:27 ` jason at gcc dot gnu.org
2011-12-09 20:09 ` jason at gcc dot gnu.org
2011-12-12 12:41 ` rguenth at gcc dot gnu.org
2011-12-12 12:46 ` rguenth at gcc dot gnu.org
2011-12-14 14:34 ` rguenth at gcc dot gnu.org
2011-12-14 15:14 ` rguenth at gcc dot gnu.org
2011-12-14 15:32 ` rguenth at gcc dot gnu.org
2011-12-14 16:04 ` rguenth at gcc dot gnu.org
2011-12-15  9:46 ` rguenth at gcc dot gnu.org
2011-12-15  9:52 ` rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).