This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Enale -fno-fat-lto-objects by default
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, dj at redhat dot com
- Date: Tue, 19 Nov 2013 11:21:48 +0100
- Subject: Re: Enale -fno-fat-lto-objects by default
- Authentication-results: sourceware.org; auth=none
- References: <20131118180458 dot GH11338 at kam dot mff dot cuni dot cz> <20131118184331 dot GA10148 at x4> <20131118190940 dot GA26530 at kam dot mff dot cuni dot cz> <528B24D5 dot 4020504 at gnu dot org> <20131119100506 dot GB10148 at x4>
> On 2013.11.19 at 09:44 +0100, Paolo Bonzini wrote:
> > Il 18/11/2013 20:09, Jan Hubicka ha scritto:
> > >>> > > this patch switches the default for fat-lto-objects as was documented for a while.
> > >>> > > -ffat-lto-objects doubles compilation time and often makes users to not notice that
> > >>> > > LTO was not used at all (because they forgot to use gcc-ar/gcc-nm plugins).
> > >>> > >
> > >>> > > Sadly I had to add -ffat-lto-objects to bootstrap. This is because I do not know
> > >>> > > how to convince our build machinery to use gcc-ar/gcc-nm during the stage2+
> > >> >
> > >> > I've posted a minimal patch set for slim-lto-bootstrap last year, see:
> > >> > http://thread.gmane.org/gmane.comp.gcc.patches/270842
> > >> >
> > >> > If there's interest I could repost it.
> > > It would be really nice to have it in indeed. I think we do not really need
> > > lto-bootstrap.mk and slim-lto-bootstrap.mk, but otherwise the patch seems easy
> > > enough and would save quite some of lto bootstrap testing time...
> >
> > Patches 1 and 2 should go upstream first.
>
> OK, but where is upstream?
> Please note that a general libtool update would fix this issue, too.
> So, maybe it is just time to upgrade libtool everywhere in gnu-land?
>
> > Patch 3 in the series is wrong because Makefile.in is a generated file.
> > The message does not explain why it is necessary, and it is probably
> > working around a bug elsewhere.
> > For patch 4, I agree with Jan that we do not need a separate configuration.
>
> The problem is that fixincl links with libiberty.a:
>
> /var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/
> -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/x86_64-pc-linux-gnu/include -isystem
> /usr/x86_64-pc-linux-gnu/sys-include -O2 -pipe -static-libstdc++
> -static-libgcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o
> procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a
>
> And this archive consists of object files with LTO sections only. So we
> need to find a way to pass -fuse-linker-plugin to the invocation above.
-fuse-linker-plugin is now default at the same time as -fno-fat-object-files is,
so there should be no need for using this switch explicitely.
Honza
>
> --
> Markus