From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11144 invoked by alias); 16 Jun 2014 13:38:47 -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 11134 invoked by uid 89); 16 Jun 2014 13:38:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jun 2014 13:38:45 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1WwX7F-0006ig-00; Mon, 16 Jun 2014 13:38:29 +0000 Date: Mon, 16 Jun 2014 13:38:00 -0000 From: Rich Felker To: Jan Hubicka Cc: Alexander Monakov , Jeff Law , Richard Biener , GCC Patches Subject: Re: [PATCH] proposed fix for bug # 61144 Message-ID: <20140616133829.GY179@brightrain.aerifal.cx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140616090604.GB14894@kam.mff.cuni.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-06/txt/msg01281.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? > 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. > 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. Rich