From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30717 invoked by alias); 14 Jun 2014 21:24:28 -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 30697 invoked by uid 89); 14 Jun 2014 21:24:27 -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; Sat, 14 Jun 2014 21:24:26 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1WvvQr-0003Vi-00; Sat, 14 Jun 2014 21:24:13 +0000 Date: Sat, 14 Jun 2014 21:24:00 -0000 From: Rich Felker To: Alexander Monakov Cc: Jeff Law , Richard Biener , Jan Hubicka , GCC Patches Subject: Re: [PATCH] proposed fix for bug # 61144 Message-ID: <20140614212413.GN179@brightrain.aerifal.cx> References: <20140521015948.GA21600@brightrain.aerifal.cx> <20140522035942.GG507@brightrain.aerifal.cx> <537F92CA.8090808@redhat.com> <20140606171424.GC179@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-06/txt/msg01185.txt.bz2 Ping. Do you have any feedback on my tests? What is the next step? Rich On Mon, Jun 09, 2014 at 03:40:44PM +0400, Alexander Monakov wrote: > > > On Fri, 6 Jun 2014, Rich Felker wrote: > > > On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote: > > > On 05/21/14 21:59, Rich Felker wrote: > > > >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote: > > > >>On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote: > > > >>>Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc > > > >>>due to aggressive and semantically-incorrect constant folding of weak > > > >>>aliases. The attached patch seems to fix the issue. A weak alias > > > >>>should never be a candidate for constant folding because it may always > > > >>>be replaced by a strong definition from another translation unit. > > > >>> > > > >>>For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 > > > >>> > > > >>>I do not have a copyright assignment on file but this patch should be > > > >>>sufficiently trivial not to require it. > > > >> > > > >>Please add a testcase. Also I wonder why it isn't better to generalize > > > > > > > >How should a testcase be done? On the PR there's a testcase that shows > > > >the problem in the generated code, but no automated check for it. > > > >Testing this is actually a bit of a pain unless you're allowed to run > > > >the generated program. > > > You can run the test program. Have it exit (0) on success, abort () > > > on failure if at all possible. Then drop the test source file into > > > gcc/testsuite/gcc.c-torture/execute/pr61144.c > > > > The test needs to be two translation units linked together: one with > > a weak definition of the object as 0, and the other with a strong > > definition. The test should show the weak value being used rather than > > the strong one. But I'm not sure how this should be integrated with > > the build process. > > Please have a look at gcc/testsuite/gcc.dg/special/wkali-2{,a,b}.c. This is a > three-TU test for weak aliases, so you should be able to very easily adjust it > for this bug. > > Thanks. > Alexander