From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1109 invoked by alias); 14 Apr 2014 22:56:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1097 invoked by uid 89); 14 Apr 2014 22:56:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f180.google.com Received: from mail-ve0-f180.google.com (HELO mail-ve0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 14 Apr 2014 22:56:34 +0000 Received: by mail-ve0-f180.google.com with SMTP id jz11so8113593veb.39 for ; Mon, 14 Apr 2014 15:56:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LMheS1kWQDRUoa13NFQf3zK+bj+cC5/Ju/ouJBIXx9U=; b=Ig2xKzG16Xb3VZpFso/H4IqTMjeAyOvm+TABjjir23k4GPYOHEmFYA3TCqCcqJMIOX mIzXPK5DRj9gaRpEt0wHUmFuMMl0EQ/a6OAO3B//dA0IWs82JweJwpa4hghVX/PNnIJQ NV08BENEIA8WWtldbsy7TXHV48YWCl/3hIDBPLou6mdRbSXLS6c8XIynQ3DxOI5UX44g bIixJFLirMc3juz7bpU2gu6BDMeUGGHdUyXfLPlGo4bSRI50DiUtf6dIawx61E+7BjNO QlyXvktW0t8jDs2G9LeOVl2EXpB+xvVa9MpAV2nGBetE2AqpAdFKNFhLT8rZ1lNMoeRM tBCw== X-Gm-Message-State: ALoCoQmqTmyNYQTOC1xEqLc0J5NUl6bk3GzpBsP4cgo09gD+REmOFX/C9l+g2BMI1l/pcaq1Lfap0LV7/OzWFm8luxHnyNOShAIjmVxGjv2K42qqvD4t7WO2hE8SK9PSsoiiLgUAsZ8DtOODGhfHiZSCUGk66hrWyVBFp1sCLBzBLKpckxfHYM0Jo+iPFRI2QmyjNYLg5G5vJjXER7aa5VlkIeR3XvWkxw== MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr38904126vcy.8.1397516191675; Mon, 14 Apr 2014 15:56:31 -0700 (PDT) Received: by 10.52.13.101 with HTTP; Mon, 14 Apr 2014 15:56:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 22:56:00 -0000 Message-ID: Subject: Re: [patch] Fix unused static symbols so they're not dropped by clang From: Doug Evans To: David Blaikie Cc: Andrew Pinski , gdb-patches , Eric Christopher Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00285.txt.bz2 On Sun, Apr 13, 2014 at 12:11 AM, David Blaikie wrote: > On Fri, Apr 11, 2014 at 9:00 PM, Andrew Pinski wrote: >> On Fri, Apr 11, 2014 at 1:17 PM, David Blaikie wrote: >>> On Fri, Apr 11, 2014 at 11:23 AM, Doug Evans wrote: >>>> On Thu, Apr 10, 2014 at 11:51 PM, David Blaikie wrote: >>>>> Several tests used file-static functions and variables that were not >>>>> referenced by the code. Even at -O0, clang omits these entities at the >>>>> frontend so the tests fail. >>>>> >>>>> Since it doesn't look like these tests needed this functionality for >>>>> what they were testing, I've modified the variables/functions to >>>>> either be non-static, or marked them with __attribute__((used)). >>>>> >>>>> If it's preferred that I use the attribute more pervasively, rather >>>>> than just making the entities non-static, I can provide a patch for >>>>> that (or some other preferred solution). There's certainly precedent >>>>> for both (non-static entities and __attribute__((used)) in the >>>>> testsuite already and much more of the former than the latter). >>>>> >>>>> I have commit-after-review access, so just looking for sign-off here. >>>> >>>> Yikes. >>>> >>>> This is becoming more and more painful (not your fault of course!). >>>> I can imagine this being a never ending source of regressions. >>>> >>>> Does clang perchance have a -O0-and-yes-I-really-mean-O0 option? >>> >>> Sort of. It does have -femit-all-decls, which, though poorly named, >>> causes clang to produce definitions for unused static entities and >>> even unused inline functions (which GCC doesn't do). >> >> By default GCC does not keep unused inline functions but there is an >> option for that -fkeep-inline-functions. > > Ah, good to know. > > My point was that the GDB test suite passes without enabling that flag > for GCC and I think that's somewhat akin to having the suite passable > without having to add -femit-all-decls for Clang. I realize, of > course, that most GDB developers won't be running the test suite with > Clang, but I'm happy to contribute patches when this comes up from > time to time. It's certainly not a pervasive habit across the test > suite to keep everything static - just this handful of tests happen to > do it. > > But I'm open to whatever you folks think is the best approach - if > that means Clang only passes the suite when passing particular flags, > so be it. Perhaps there'd be a way we could build that knowledge into > the testsuite itself so that GDB developers who want to use Clang > don't have to duplicate those details locally. I don't have a strong preference other than trying to keep things maintainable. Maybe it would be enough to document the issue in the testsuite coding standards section of the manual. This is a really subtle portability issue though ... *something* in the code would be nice.