From patchwork Mon Jun 4 08:55:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 162682 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E0F43B703D for ; Mon, 4 Jun 2012 18:55:42 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1339404943; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=qQwmpuWnwO1F0Jwt5XrFHYP0fIA=; b=cA/YYxlEXAF/swK mRLy42zu3GdpwEsL7nKGzvc9fZ0BkC7k0udsCx2+15kPgLQTeq/SjuaIQuQI8vWt hpqZ1EdlJbAirZaBdOoyX+PU6L4zK0dG7o9mQ8N1OXHinFkGaFhQZEZJItoAXOzQ bYPv1Vr+7lBCQZ7FGY5sCxpA0Rpc= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ckPs5K0ogqDB85IA0NhRJtlrqnSDBAoCa+i2Jw0egKD05G8v6atQpzMqT1lUrd HwpRbD8Q9iVkhbN0qFCj1X3MD4oJ/M3gCku/a4r2yJ+TtaxAF7qT0uCyEFi1LRzj oTkjomfy6zqJbKz2I+57s9awIm2QhBwJBL9AqTSSDg9X8=; Received: (qmail 9004 invoked by alias); 4 Jun 2012 08:55:36 -0000 Received: (qmail 8992 invoked by uid 22791); 4 Jun 2012 08:55:34 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Jun 2012 08:55:07 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 95EF5A2BD7; Mon, 4 Jun 2012 10:55:05 +0200 (CEST) Date: Mon, 4 Jun 2012 10:55:05 +0200 (CEST) From: Richard Guenther To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR53471, remove DECL_ASSEMBLER_NAME deferred compute In-Reply-To: <4FC8E128.2030309@redhat.com> Message-ID: References: <4FC7D28E.5010801@redhat.com> <4FC8E128.2030309@redhat.com> MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Fri, 1 Jun 2012, Jason Merrill wrote: > On 06/01/2012 05:22 AM, Richard Guenther wrote: > > On Thu, 31 May 2012, Jason Merrill wrote: > > > > > The comment mentions PCH in connection with deferred seting of > > > DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that > > > might be > > > connected with anonymous unions, which need to have different linkage > > > names in > > > different translation units. > > > > Not sure when PCH generation happens (or when we call > > rest_of_type_compilation), but shouldn't that be way earlier than > > the debug output? > > PCH generation happens at the beginning of cp_write_global_declarations; > rest_of_type_compilation, which triggers the debug output, is called after > each class definition. > > > Anyway, any suggestion on how to tackle the issue > > that we cannot compute new DECL_ASSEMBLER_NAMEs after the frontend > > is finished? > > Fix up the deferred_asm_name list somewhere between the call to > c_common_write_pch and the call to free_lang_data. I guess this would mean > another debug hook for processing that needs to happen before free_lang_data. That's certainly possible - add a finish_compilation_unit debug hook. I'll think about that for 4.8. > Or fix free_lang_data to deal with these types, too. Unfortunately they are not "reachable" from anything but the deferred_asm_name list. So it would mean another debug hook. > Or use your first patch, and decide that we don't care about the linkage name > of unreachable types. What types are affected by this, anyway? Types affected by this are types not referenced from any object/function that is being output as LTO bytecode (and the type will not be output as LTO bytecode either, so at LTO time we'd not generate debuginfo for it either). It's basically completely "unused" types that are affected. I suppose that's indeed the easiest fix - all "important" types should have been assigned an assembler name by free-lang-data. One issue is that free-lang-data (and its assembler name assigning code) is not run if -flto is not enabled ... So I suppose for the 4.7 branch we'd go with and for trunk change two things - make sure the assembler-name assigning piece of free-lang-data runs unconditionally and a debug hook is added so we can output debuginfo dependent on langhooks. I am going to test the above and install it on trunk and the branch for now to get into 4.7.1. Thanks, Richard. Index: dwarf2out.c =================================================================== --- dwarf2out.c (revision 188106) +++ dwarf2out.c (working copy) @@ -22158,7 +22158,8 @@ dwarf2out_finish (const char *filename) for (node = deferred_asm_name; node; node = node->next) { tree decl = node->created_for; - if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl)) + if ((!flag_generate_lto || DECL_ASSEMBLER_NAME_SET_P (decl)) + && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl)) { add_linkage_attr (node->die, decl); move_linkage_attr (node->die);