This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch ping


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]