* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
@ 2014-01-21 2:02 ` joseph at codesourcery dot com
2014-01-21 6:19 ` glisse at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: joseph at codesourcery dot com @ 2014-01-21 2:02 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
2014-01-21 2:02 ` [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc joseph at codesourcery dot com
@ 2014-01-21 6:19 ` glisse at gcc dot gnu.org
2014-01-21 19:06 ` glisse at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-01-21 6:19 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
2014-01-21 2:02 ` [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc joseph at codesourcery dot com
2014-01-21 6:19 ` glisse at gcc dot gnu.org
@ 2014-01-21 19:06 ` glisse at gcc dot gnu.org
2014-01-22 22:16 ` glisse at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-01-21 19:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-01-21 19:06 ` glisse at gcc dot gnu.org
@ 2014-01-22 22:16 ` glisse at gcc dot gnu.org
2014-01-29 10:09 ` rguenth at gcc dot gnu.org
2014-02-12 16:26 ` d.g.gorbachev at gmail dot com
5 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-01-22 22:16 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-01-22 22:16 ` glisse at gcc dot gnu.org
@ 2014-01-29 10:09 ` rguenth at gcc dot gnu.org
2014-02-12 16:26 ` d.g.gorbachev at gmail dot com
5 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-29 10:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
[not found] <bug-59893-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-01-29 10:09 ` rguenth at gcc dot gnu.org
@ 2014-02-12 16:26 ` d.g.gorbachev at gmail dot com
5 siblings, 0 replies; 6+ messages in thread
From: d.g.gorbachev at gmail dot com @ 2014-02-12 16:26 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread