From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5583 invoked by alias); 14 Apr 2014 11:02:24 -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 5566 invoked by uid 89); 14 Apr 2014 11:02:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Apr 2014 11:02:21 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3EB2Jo7024335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Apr 2014 07:02:19 -0400 Received: from tucnak.zalov.cz (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3EB2HDH022261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Apr 2014 07:02:19 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s3EB2CmV010419; Mon, 14 Apr 2014 13:02:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s3EB29MU010418; Mon, 14 Apr 2014 13:02:09 +0200 Date: Mon, 14 Apr 2014 11:02:00 -0000 From: Jakub Jelinek To: DJ Delorie Cc: bonzini@gnu.org, aoliva@redhat.com, Ralf.Wildenhues@gmx.de, rguenther@suse.de, gcc-patches@gcc.gnu.org Subject: Re: Patch ping Message-ID: <20140414110209.GO1817@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140409130721.GK1817@tucnak.redhat.com> <201404092229.s39MTmXp015920@greed.delorie.com> <20140410055906.GP1817@tucnak.redhat.com> <201404101601.s3AG1VSv012678@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404101601.s3AG1VSv012678@greed.delorie.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00664.txt.bz2 On Thu, Apr 10, 2014 at 12:01:31PM -0400, DJ Delorie wrote: > > But ubsan is a new feature in 4.9, and it is a bootstrap failure > > with that feature. > > I will leave it up to the release manager to decide if they want this > non-regression patch applied before the branch, then. > > > This is for the host libiberty only, and only when gcc is configured > > a certain way. The intent is to have libiberty that is going to be > > linked into all the build and host tools instrumented, so that we > > actually catch bugs in libiberty or bugs in host/build tools calling > > libiberty functions as much as possible, but for the lto-plugin, > > which is dlopened by the linker which we don't have a control on, we > > need host libiberty without the address sanitization because > > otherwise it would only work properly if the linker itself has been > > address sanitized. > > So, if libiberty isn't built with sanitization, it would still *work* > but not be instrumented? Certainly. If libiberty isn't built with sanitization (that is the normal case), then even nothing changes in the way it is built. The problem is only when it is built with sanitization that we actually for the lto-plugin (and whatever else is built as an dlopenable module, not an application) need a variant of the host libiberty that isn't built with sanitization (talking about asan only here, ubsan can handle this). So, now that 4.9 has branched, are both patches ok for trunk, or just the first one? The first one fixes --with-build-config=bootstrap-ubsan fully and --with-build-config=bootstrap-asan partially, the second one --with-build-config=bootstrap-asan fully. Jakub