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
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=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=19842
--- Comment #29 from hubicka at ucw dot cz ---
> /* Skip weak definitions of symbols that are already defined. */
> if (newdef && olddef && newweak)
> {
> /* Don't skip new non-IR weak syms.
https://sourceware.org/bugzilla/show_bug.cgi?id=17422
--- Comment #4 from hubicka at ucw dot cz ---
Actually I think gold&ld 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
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-binut
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.
Ho
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
W
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 fro
http://sourceware.org/bugzilla/show_bug.cgi?id=14342
--- Comment #3 from hubicka at ucw dot cz ---
> Are you using a recent version of gold? I think the TLS problem should
> have been fixed with this patch:
>
> http://sourceware.org/ml/binutils/2013-06/msg00139.html
This indee
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
http://sourceware.org/bugzilla/"; />
http://sourceware.org/bugzilla/show_bug.cgi?id=15516#c9";>Comment #
9
on http://sourceware.org/bugzilla/show_bug.cgi?id=15516";>bug 15
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 201
3-05-24 12:36:57 UTC ---
> Hello,
>I've just tried to build libreoffice with GNU ld (Linu
http://sourceware.org/bugzilla/show_bug.cgi?id=15516
--- Comment #4 from hubicka at ucw dot cz 2013-05-24 11:42:48 UTC ---
> I could not reproduce this with current mainline binutils. The following
> extract from a debug session shows one of the typeinfo symbols hitting
> _bfd_exf_expo
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 2013-05-22 16:24:05
> UTC ---
> By "turned into static" do you mean that the typeinfo symbol in the real
>
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=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=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)
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 t
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 H
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 2011-10-03
> 21:50:21 UTC ---
> > Here the function test
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
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 2011-10-02
> 13:01:38 UTC ---
> What about the following naive p
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
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 solut
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=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 tole
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.
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
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!
http://sourceware.org/bugzilla/show_bug.cgi?id=12944
--- Comment #4 from hubicka at ucw dot cz 2011-06-28 15:21:21 UTC ---
> Are you referring to
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
>
> It failed even without LTO.
Hmm,
I re-updated GNU LD and it indeed seems t
30 matches
Mail list logo
