Re: Enale -fno-fat-lto-objects by default

[Paolo Bonzini <bonzini at gnu dot org>]

Il 19/11/2013 11:05, Markus Trippelsdorf ha scritto:
> 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.

Ah, so they're already upstream.

> So, maybe it is just time to upgrade libtool everywhere in gnu-land?

Yes, that would be better but no need to do that now.

>> 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.

Then -fuse-linker-plugin should be added to the LDFLAGS (not CFLAGS) for
all host modules, as in "LDFLAGS += -fuse-linker-plugin".  Other host
modules than fixincludes could also use libiberty or another
bootstrapped host library (libbfd is one, I think), and would require
the same fix.

Paolo