From patchwork Sun Dec 30 00:22:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 208688 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 E66322C00B9 for ; Sun, 30 Dec 2012 11:23:29 +1100 (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=1357431810; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=5c9yCiyIZdP7R24rGeAL 3qDQJpU=; b=eUlcRW8HgaBuVtn9ejrrrNjuKjjh6TqZoyNfPbpgDK7mue930c1T elMIgttlQlesxI+LD7ugh3wcvjW/FWJDU5PacSYHwlwHZcSGwsdwDtQzvqyqAonp Y4nWC4MZPNrCvefHXIyKJRV16Qzs77A/H4LVzcbmWmDPS38YRGpPl3A= 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:Received:Received:Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Mw6QA1bzGUcr1OWpmbppKxPSe7ErHVhXJet3U9G+Gmuqqm4chMcdttibXw4eqo r6YxHuAArCG7y9JbzFbpccb5qgWqNN5eTIoIOlJwQ/333Bp97/+GRL/PVG+x6UMB fmeDgxRzsaXKmWnCnixpUbcOciAKHtlwcfbqMzfVZc6eU=; Received: (qmail 15832 invoked by alias); 30 Dec 2012 00:23:23 -0000 Received: (qmail 15824 invoked by uid 22791); 30 Dec 2012 00:23:22 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 30 Dec 2012 00:23:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBU0NFPW017775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Dec 2012 19:23:15 -0500 Received: from freie (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBU0N9iG001047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Dec 2012 19:23:14 -0500 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie (8.14.5/8.14.5) with ESMTP id qBU0N1EF031774; Sat, 29 Dec 2012 22:23:07 -0200 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qBU0MrLH016525; Sat, 29 Dec 2012 22:22:53 -0200 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id qBU0Mqw7016523; Sat, 29 Dec 2012 22:22:52 -0200 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PR libmudflap/53359] don't register symbols not emitted References: Date: Sat, 29 Dec 2012 22:22:51 -0200 In-Reply-To: (Richard Biener's message of "Fri, 21 Dec 2012 10:50:58 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) 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 Dec 21, 2012, Richard Biener wrote: > On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote: >> libmudflap emits a global initializer that registers memory ranges for >> global data symbols. However, even if IPA decides not to emit a symbol >> because it's unused, we'd still emit registration sequences for them in >> some cases, which, in the PR testcase, would result in TOC references to >> the undefined symbols. > Hmm, I think that at this point of the compilation you are looking for > TREE_ASM_WRITTEN instead. That doesn't work, several mudflap regressions show up because accesses to global library symbols that are accessed by template methods compiled with mudflap (say cout) are then verified but not registered. We have to register symbols that are not emitted but that referenced. I've now updated the comment to reflect this. Is this ok to install? Regstrapped again (along with the patches for feraiseexcept, since there weren't any non-comment changes here) on x86_64-linux-gnu and i686-linux-gnu. don't let mudflap register global symbols that won't be emitted From: Alexandre Oliva for gcc/ChangeLog PR libmudflap/53359 * tree-mudflap.c (mudflap_finish_file): Skip deferred decls not found in the symtab. --- gcc/tree-mudflap.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/gcc/tree-mudflap.c b/gcc/tree-mudflap.c index 90d0448..e20f06e 100644 --- a/gcc/tree-mudflap.c +++ b/gcc/tree-mudflap.c @@ -1335,6 +1335,16 @@ mudflap_finish_file (void) if (! TREE_PUBLIC (obj) && ! TREE_ADDRESSABLE (obj)) continue; + /* If we're neither emitting nor referencing the symbol, + don't register it. We have to register external symbols + if they happen to be in other files not compiled with + mudflap (say system libraries), and we must not register + internal symbols that we don't emit or they'll become + dangling references or force symbols to be emitted that + didn't have to. */ + if (!symtab_get_node (obj)) + continue; + if (! COMPLETE_TYPE_P (TREE_TYPE (obj))) { warning (OPT_Wmudflap,