Re: [debug-early] revert removal of deferred_asm_names

Re: [debug-early] revert removal of deferred_asm_names

[Richard Biener]

On Fri, May 1, 2015 at 1:28 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> Hello gentlemen.
>
> Both of you suggested I revert my removal of deferred_asm_names from
> dwarf2out, since it may cause mangling of DECLs that may ultimately not be
> needed.
>
> A little background...
>
> This all started with a regression for pr44197.c in the branch.  What is
> happening is that the C front-end uses the presence of DECL_ASSEMBLER_NAME
> to determine if an __asm__ alias is already present for a symbol.
> Unfortunately, passing said symbol through dwarf2out_early_global_decl,
> triggers DECL_ASSEMBLER_NAME, so all symbols will have their assembler name
> set, and there is no way to diagnose multiple conflicting __asm__ aliases.
>
> Having thought about this some more, unless I'm misunderstanding something,
> I don't thing we'll cause mangling of DECLs that may not be eventually
> mangled.  I mean, everything that ends up in deferred_asm_name, will
> ultimately end up in a DIE that will ultimately get a mangled
> DECL_ASSEMBLER_NAME.  It's not like we're pruning unused DIEs _before_ we
> iterate through deferred_asm_name and generate DECL_ASSEMBLER_NAMEs for them
> (in mainline).
>
> For that matter, the original reason for deferred_asm_name was not to avoid
> mangling but to avoid template instantiation (something which Jason fixed in
> mainline as part of my original removal of deferred_asm_name).  The original
> raison d'etre is here:
>
>         https://gcc.gnu.org/ml/gcc-patches/2009-06/msg00030.html
>
> (Unless of course, another reason for deferred_asm_names was to avoid
> bloating memory usage earlier in the compilation process???  Although if
> we're going to generate the field, does it matter that much if we do it
> earlier?)
>
> Be that as it may, even if you agree with me, the pr44197.c regression needs
> to be addressed, and resurrecting deferred_asm_names does the trick of
> delaying setting DECL_ASSEMBLER_NAME until after the parser has finished.
>
> With this patch I have moved the flushing of deferred_asm_names to
> dwarf2out_early_finish instead of dwarf2out_finish, so it happens after the
> parser has finished, but does not live past LTO and upset Richi ;-).
>
> Could either of you comment on this, so I may at least add a relevant
> comment to the reason for deferred_asm_names (whether it exists to avoid
> parser insanity or to avoid unnecessary mangling)?
>
> Either way, I'm committing to the branch.  Regressions down to 2.

Great.  Btw, I wonder if we can't re-write the C FE diagnostic to use the
symbol-table aliases list?

Richard.

> Aldy