From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27674 invoked by alias); 2 May 2015 11:29:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27660 invoked by uid 89); 2 May 2015 11:29:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 02 May 2015 11:29:53 +0000 Received: by oift201 with SMTP id t201so85085827oif.3 for ; Sat, 02 May 2015 04:29:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.172.196 with SMTP id v187mr10494901oie.51.1430566191727; Sat, 02 May 2015 04:29:51 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Sat, 2 May 2015 04:29:51 -0700 (PDT) In-Reply-To: <5542BA95.5010106@redhat.com> References: <5542BA95.5010106@redhat.com> Date: Sat, 02 May 2015 11:29:00 -0000 Message-ID: Subject: Re: [debug-early] revert removal of deferred_asm_names From: Richard Biener To: Aldy Hernandez Cc: jason merrill , Jakub Jelinek , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00128.txt.bz2 On Fri, May 1, 2015 at 1:28 AM, Aldy Hernandez 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