On Fri, May 1, 2015 at 1:28 AM, Aldy Hernandez <al...@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
