PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

Jakub Jelinek jakub@redhat.com
Mon Nov 10 13:45:00 GMT 2014


On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
> >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
> >> > Hi,
> >> >
> >> > r216964 disables bootstrap for libcc1 which exposed 2 things:
> >> >
> >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
> >> > "--with-build-config=bootstrap-lto".  It may be intentional since
> >> > libcc1 is disabled for bootstrap.
> >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
> >> > compiled with LTO which remembers PIC option.
> >>
> >> Why is this any special to LTO?  If it is then it looks like a LTO
> >> (driver) issue to me?  Why are we linking the pic libibterty into
> >> a non-pic libcc1?
> >
> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> > libcc1 is built normally using libtool using -fPIC only, and linked into
> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
> > pic/libiberty.a, because we need PIC code in the shared libraries.
> > So, I don't understand the change at all.
> >
> >         Jakub
> 
> This is the command line to build libcc1.la:

Sure, but there was -fPIC used to compile all the *.o files that are being
linked into libcc1.so, so LTO should know that.

	Jakub



More information about the Gcc-patches mailing list