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.
