Bug 48508 - ICE in output_die, at dwarf2out.c:11409
Summary: ICE in output_die, at dwarf2out.c:11409
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Richard Biener
URL:
Keywords:
Depends on: 51573
Blocks: mozillametabug 47819
  Show dependency treegraph
 
Reported: 2011-04-07 23:21 UTC by Jan Hubicka
Modified: 2011-12-16 10:21 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-04-22 09:32:12


Attachments
testcase (875.99 KB, application/x-bzip)
2011-04-07 23:25 UTC, Jan Hubicka
Details
reduced testcase (5.65 KB, application/octet-stream)
2011-05-26 11:51 UTC, Richard Biener
Details
Patch to avoid generating abstract function for block extern (387 bytes, patch)
2011-12-09 20:04 UTC, Jason Merrill
Details | Diff
manually reduced testcase (722 bytes, text/plain)
2011-12-12 12:40 UTC, Richard Biener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2011-04-07 23:21:40 UTC
/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.
Comment 1 Jan Hubicka 2011-04-07 23:25:43 UTC
Created attachment 23922 [details]
testcase
Comment 2 Richard Biener 2011-04-08 10:09:15 UTC
I think I've seen this before ...
Comment 3 Jan Hubicka 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.
Comment 4 Jan Hubicka 2011-04-22 09:32:12 UTC
Still reproduce at current mainline.
Comment 5 Richard Biener 2011-05-26 11:51:37 UTC
Created attachment 24363 [details]
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.
Comment 6 Joshua Conner 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?
Comment 7 Richard Biener 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 ... :/
Comment 8 Jason Merrill 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.
Comment 9 Jason Merrill 2011-12-09 20:04:44 UTC
Created attachment 26035 [details]
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.
Comment 10 Richard Biener 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.
Comment 11 Richard Biener 2011-12-12 12:40:42 UTC
Created attachment 26056 [details]
manually reduced testcase
Comment 12 Richard Biener 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.
Comment 13 Richard Biener 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.
Comment 14 Richard Biener 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.
Comment 15 Richard Biener 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).
Comment 16 Richard Biener 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
Comment 17 Richard Biener 2011-12-15 09:49:36 UTC
Fixed.