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?
