From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5657 invoked by alias); 16 Jun 2014 16:05:26 -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 5646 invoked by uid 89); 16 Jun 2014 16:05:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 16 Jun 2014 16:05:23 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id C6B02541C92; Mon, 16 Jun 2014 18:05:19 +0200 (CEST) Date: Mon, 16 Jun 2014 16:05:00 -0000 From: Jan Hubicka To: Rich Felker Cc: Jan Hubicka , Alexander Monakov , Jeff Law , Richard Biener , GCC Patches Subject: Re: [PATCH] proposed fix for bug # 61144 Message-ID: <20140616160519.GB12467@kam.mff.cuni.cz> References: <20140521015948.GA21600@brightrain.aerifal.cx> <20140522035942.GG507@brightrain.aerifal.cx> <537F92CA.8090808@redhat.com> <20140606171424.GC179@brightrain.aerifal.cx> <20140609184601.GI179@brightrain.aerifal.cx> <20140616090604.GB14894@kam.mff.cuni.cz> <20140616133829.GY179@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140616133829.GY179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-06/txt/msg01292.txt.bz2 > On Mon, Jun 16, 2014 at 11:06:04AM +0200, Jan Hubicka wrote: > > > > > > Are the attached files acceptable? > > > > The testcase looks OK to me, but it already should be fixed on mainline > > by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that > > prevents dummy to be marked as constant. > > > > You can however modify the testcase to have > > __attribute__ ((weak)) const int foo=0; > > And the same for weak alias rather than straight weak definition like > the above? Yes, if you add const to your testcase, it will get miscompiled by mainline again. > > > This needs your decl_replaceable change to not be optimized to if (0), > > because of the explicit const modifier. > > The case I care about actually has "dummy" as const (with the intent > that it be allocated in a read-only section if the dummy definition is > used). So for me it's important that this regression be fixed too. Yep, GCC since 90's was optimizing reads from weak const attributes, but it because worse because I added code walking through aliases. > > > I did not change ctor_for_folding to reject variables above as I was not quite > > sure we want to support this kind of interposition and I am still not quite certain. > > C++ is quite clear about the transformation replacing initialized const by its value. > > My concern is about C, not C++. This kind of interposition has always > been supported in unix C, even prior to GCC, going back to sysv or > earlier, as a documented feature (historically #pragma weak). It > should not regress. If fixing it results in an regression with regards > to optimizability of C++, perhaps this could be made > language-specific, or (better) the C++ front-end could add an > additional internal-use-only attribute to weak definitions it > generates internally that permits constant-folding them, while not > breaking the semantics for weak definitions provided by the user at > the source level. Yes, I see your point and clearly we should not optimize with explicit weak attribute. I wonder if decl_replaceable_p is however correct check here or if we want explicit check for weak visibility. I am concerned about const variables w/o weak attribute with -fPIC (because for those decl_replaceable_p returns true, too). Consider following testcase: struct t { static const int dummy=0; const int *m(); } t; int main() { return *t.m(); } int main2() { return t.dummy; } const int * t::m() { return &dummy; } Here main2 is optimized by C++ FE to return 0, while backend is affraid to optimize main() after inlining anticipating that dummy may be interposed. However moving t::m inside of the unit will make dummy comdat and it will get optimizing. Adding another method and keying the t into other unit will make it optimized, too. This is not very consistent. But perhaps we need a flag from C++ FE to tell us what variables may not be interposed, because perhaps the c variant with -fPIC const int dummy=0; int main() { return t; } Jason? A C variant of the testcase: const int dummy=0; const static int * d=&dummy; int main() { return dummy; } int main2() { return *d; } seems optimized to return 0 (with -fPIC) for ages, too, but here at least frontend won't substitute first dummy for 0. Honza