From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3138 invoked by alias); 10 Apr 2014 05:59:21 -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 3126 invoked by uid 89); 10 Apr 2014 05:59:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 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; Thu, 10 Apr 2014 05:59:19 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3A5xIdt004552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Apr 2014 01:59:18 -0400 Received: from tucnak.zalov.cz (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3A5xGmM025472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Apr 2014 01:59:17 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s3A5xBKH029969; Thu, 10 Apr 2014 07:59:12 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s3A5x6Dh029968; Thu, 10 Apr 2014 07:59:06 +0200 Date: Thu, 10 Apr 2014 05:59: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: <20140410055906.GP1817@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140409130721.GK1817@tucnak.redhat.com> <201404092229.s39MTmXp015920@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404092229.s39MTmXp015920@greed.delorie.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00471.txt.bz2 On Wed, Apr 09, 2014 at 06:29:48PM -0400, DJ Delorie wrote: > > > - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html > > PR sanitizer/56781 > > fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin > > I have no particular problem with this patch, although the build has > gotten beyond my full understanding these days... > > However, does this fix a regression? If not, it should wait for > stage1. But ubsan is a new feature in 4.9, and it is a bootstrap failure with that feature. > > - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html > > PR sanitizer/56781 > > fix --with-build-config=bootstrap-asan bootstrap of lto-plugin > > Are we really going to multilib libiberty for every "useful" option we > think of? For the build/host, we have a generic way of providing > CFLAGS, and for the target we already have a multilib structure. 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. Jakub