[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77278 --- Comment #8 from Eric Gallager --- (In reply to Richard Biener from comment #6) > Confirmed. It was the original intent to allow this, esp. for libgfortran > for example. That's bug 77278
[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #7 from Dmitry Gorbachev --- 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).
[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-29 Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #5 from Marc Glisse --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #4 from Marc Glisse --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #3 from joseph at codesourcery dot com --- On Tue, 21 Jan 2014, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 > > --- Comment #2 from Marc Glisse --- > (In reply to jos...@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... My point is not just that a Canadian cross build where the target libraries get rebuilt would rebuild them with the build-x-target compiler (producing results not actually usable on the host), but that the normal case for a Canadian cross build would copy the libraries from the build-x-target compiler - which was built with build = host - rather than rebuilding them at all (using make all-host when building the Canadian cross compiler). Essentially, I'm suggesting that host-dependence of LTO information *is* a reason to consider use of LTO in GCC's libraries as something experimental and not appropriate to enable by default.
[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #2 from Marc Glisse --- (In reply to jos...@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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #1 from 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)?
