[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 20 Jan 2014, glisse at gcc dot gnu.org wrote:

> LTO is not really a brand new, experimental and exotic option anymore. I
> believe that by default, on systems that support it, we should build the static
> target libraries that are part of gcc with -flto (and obviously
> -ffat-lto-objects). This should have no impact on people not using LTO (well,

Are LTO objects now independent of the compiler host (see bug 41526) (so 
that such libraries will work properly when copied from one host to 
another as part of a Canadian cross build)?

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #1)
> Are LTO objects now independent of the compiler host (see bug 41526) (so 
> that such libraries will work properly when copied from one host to 
> another as part of a Canadian cross build)?

Thanks for the link (I don't know much about the implementation of LTO). Maybe
restricting my proposition to the case build==host would be safer? If only
native builds work, I am still ok with that, but I won't be surprised if there
are bugs preventing it...

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Joseph, thank you for those precisions, I hadn't realized the width of the
problem. Similarly, on my Debian multiarch machine, when I cross-compile for
arm, I use a libgcc.a that was built natively on arm, so that would break as
well.

I believe LTO streams come with a format version, and gcc checks that it
understands this version before proceeding (and gives an error otherwise).
Maybe it could also embed the host triple and check that it is the same. And
possibly downgrade the errors to warnings as long as we have a fat object and
can fall back to regular linking.

I understand this all makes it too early for LTO by default.

I guess a configure option --enable-lto-libraries that defaults to "no" would
still make sense, with suitably dire warnings in the doc.

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #0)
> It may be as easy as adding the flags to C(XX)FLAGS_FOR_TARGET

With a trivial fix for PR 43538, this works. However, we then hit PR 59472.
Also, if instead of gold 1.11 (which works fine) I use GNU ld 2.24, I get
warnings:
/usr/bin/ld: error in /tmp/cc5iP5Yf.ltrans2.ltrans.o(.eh_frame); no
.eh_frame_hdr table will be created.
because of crtend.o.

The path is long... At least, I tried the result, and it does help for PR 59048
and does allow removing operator delete(0).

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-29
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  It was the original intent to allow this, esp. for libgfortran
for example.  But there is quite some work needed to make it work reliably
I guess.

A configure option to enable it selectively for non-cross-builds would be nice.

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #7 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> ---
I used to build GCC 4.8/4.9 with -flto in C(XX)FLAGS_FOR_TARGET for quite some
time (both native i686-pc-linux-gnu and a cross), and it seems to work.  I saw
two problems: PR 60160 (for which a patch exists), and PR 59472 (annoying, but
not fatal).