http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #4 from hubicka at ucw dot cz 2011-09-30 16:31:05 UTC ---
Hi,
I can build Mozilla with GNU LD with resulting binary being about the same size
as gold's so it seems to be all fine.
Also the TLS problems are gone.
Thanks a lot!
Honza
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #5 from hubicka at ucw dot cz 2011-09-30 17:10:55 UTC ---
Hi,
I can build Mozilla with GNU LD with resulting binary being about the same
size
as gold's so it seems to be all fine.
Also the TLS problems are gone.
Actually I
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC ---
I guess Gold is just tolerant here and I would say that GNU LD should be too.
I will work out how this symbol appears in the symbol table.
Filled in as PR13244.
Honza
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #7 from hubicka at ucw dot cz 2011-10-01 13:50:13 UTC ---
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC ---
I guess Gold is just tolerant here and I
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #8 from hubicka at ucw dot cz 2011-10-01 14:23:01 UTC ---
Hi,
the following is a diff from GNU LD to Gold build. I previously complained
about RESOLVED_DYN/UNDEF difference. It is harmless since internall for GCC it
does not make
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #3 from hubicka at ucw dot cz 2011-10-02 10:10:58 UTC ---
I cannot reproduce this issue:
Sorry, it is because mainline still contains the hack for COMDAT handling (I
diseabled it in my tree to verify that new IRONLY solution works
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #4 from hubicka at ucw dot cz 2011-10-02 10:48:55 UTC ---
Sorry, it is because mainline still contains the hack for COMDAT handling (I
diseabled it in my tree to verify that new IRONLY solution works). You need
to
extend
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #6 from hubicka at ucw dot cz 2011-10-02 15:22:07 UTC ---
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #5 from Octoploid cryptooctoploid at gmail dot com 2011-10-02
13:01:38 UTC ---
What about
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #8 from hubicka at ucw dot cz 2011-10-02 20:50:50 UTC ---
Yes, it does solve the problem here (I have 8GB of RAM and used a
large swapfile on my SSD. It took ~10 minutes to output all ltrans.o
files).
I am surprised
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #10 from hubicka at ucw dot cz 2011-10-04 09:17:43 UTC ---
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #9 from Cary Coutant ccoutant at google dot com 2011-10-03
21:50:21 UTC ---
Here the function test
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #12 from hubicka at ucw dot cz 2011-10-04 09:41:40 UTC ---
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #11 from rguenther at suse dot de 2011-10-04 09:24:22 UTC ---
On Sun, 2 Oct 2011, Jan Hubicka wrote
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #12 from hubicka at ucw dot cz 2011-10-05 20:49:35 UTC ---
/* This is the prevailing definition of the symbol, with no
references from regular objects. It is only referenced from IR
code, but the symbol is exported
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
--- Comment #2 from hubicka at ucw dot cz 2011-10-06 18:45:42 UTC ---
jh@evans:/abuild/jh/trunk-3/build-inst7/gcc cat t.c
extern __attribute__ ((visibility(hidden))) int fooblah;
static
do_nothing (int param)
{
if (param)
fooblah = 1
http://sourceware.org/bugzilla/show_bug.cgi?id=15300
--- Comment #2 from hubicka at ucw dot cz 2013-03-24 18:02:40 UTC ---
Or better still have the utilities load the plugin automatically.
Yes, I think ideally the LTO capable compilers should install plugins into the
binutils search path
http://sourceware.org/bugzilla/show_bug.cgi?id=15300
--- Comment #3 from hubicka at ucw dot cz 2013-03-24 18:11:13 UTC ---
Independently on that however I guess binutils should know to warn when the
plugin mechanizm fails
and LTO only object is being handled the normal way.
It is really very
http://sourceware.org/bugzilla/show_bug.cgi?id=15516
--- Comment #2 from hubicka at ucw dot cz 2013-05-22 16:44:43 UTC ---
--- Comment #1 from Alan Modra amodra at gmail dot com 2013-05-22 16:24:05
UTC ---
By turned into static do you mean that the typeinfo symbol in the real
object
http://sourceware.org/bugzilla/show_bug.cgi?id=15516
--- Comment #6 from hubicka at ucw dot cz 2013-05-24 12:50:04 UTC ---
--- Comment #5 from Martin Liška marxin.liska at gmail dot com 201
3-05-24 12:36:57 UTC ---
Hello,
I've just tried to build libreoffice with GNU ld (Linux/GNU
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
html
head
base href=http://sourceware.org/bugzilla/; /
/head
body
p
div
ba class=bz_bug_link
bz_status_RESOLVED bz_closed
title=RESOLVED WORKSFORME - GNU LD is confused when
http://sourceware.org/bugzilla/show_bug.cgi?id=14342
--- Comment #5 from hubicka at ucw dot cz ---
I thought GNU ld didn't have this bug, but I'll check.
It reproduced for me for both GNU ld and gold in the latest release version.
The testcase seen by GCC may be different from normal file
https://sourceware.org/bugzilla/show_bug.cgi?id=13227
--- Comment #2 from hubicka at ucw dot cz ---
Bug 14698 Summary: ar, nm and ranlib don't use gcc's liblto_plugin.so in
BINDIR/../lib/bfd-plugins automatically
https://sourceware.org/bugzilla/show_bug.cgi?id=14698
Will we now get some sort
https://sourceware.org/bugzilla/show_bug.cgi?id=13227
--- Comment #7 from hubicka at ucw dot cz ---
So is it sufficient (and safe) to warn just on the presence of __gnu_slim_lto?
Yes, when __gnu_slim_lto gets into linking/archiving/nm, I think it is safe to
warn about
missing plugin.
Honza
https://sourceware.org/bugzilla/show_bug.cgi?id=13227
--- Comment #10 from hubicka at ucw dot cz ---
Fixed
Thanks, does this also cover gold linker?
Honza
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=17422
--- Comment #4 from hubicka at ucw dot cz ---
Actually I think goldld could be updated to load multiple plugins at once
and let different plugins to claim different object files. That way we ought
to be able to link program that contains LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=19842
--- Comment #32 from hubicka at ucw dot cz ---
> Hi all,
>
> Just following up on this as it seems to have stalled: @honza, do you concur
> this may be a bug in GCC? If so shall I file something, or are you happy to
> capture i
https://sourceware.org/bugzilla/show_bug.cgi?id=25333
--- Comment #2 from hubicka at ucw dot cz ---
The testcase was based on real world one - in C++ it is quite easy to
create many types. So it would be nice to do something about it.
--
You are receiving this mail because:
You are on the CC
https://sourceware.org/bugzilla/show_bug.cgi?id=25295
--- Comment #5 from hubicka at ucw dot cz ---
> Where do you see "export foo and foo@VERS_1"? All I see is that the alias
> gets
> the same attributes as the original symbol, thus it will be external iff the
> original
26 matches
Mail list logo
