http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #34 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-14 07:41:02 UTC ---
I've created PR53337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-10
07:35:02 UTC ---
I believe binutils 2.21.1 is not new enough, support for this was only added
on the 2.22 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #29 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-10 07:53:37 UTC ---
we will try binutil 2.22
in any case the test case is simple (with boost 1.49)
notice how w/o linker-plugin NO symbol at all are generated for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #30 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-10 15:50:15 UTC ---
using the new binutil I've no more error
still warning of the type
tmp/innocent/ccmPaLCz.ltrans6.ltrans.o:ccmPaLCz.ltrans6.o:function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #31 from Jan Hubicka hubicka at ucw dot cz 2012-05-10 17:07:47
UTC ---
using the new binutil I've no more error
still warning of the type
tmp/innocent/ccmPaLCz.ltrans6.ltrans.o:ccmPaLCz.ltrans6.o:function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #32 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-10 17:13:20 UTC ---
On 10 May, 2012, at 7:07 PM, hubicka at ucw dot cz wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #31 from Jan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #26 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-02
10:41:27 UTC ---
Author: hubicka
Date: Sun Oct 2 10:41:24 2011
New Revision: 179424
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179424
Log:
PR lto/47247
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-28
12:38:29 UTC ---
Thanks for gold support. GCC support is now posted at
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01818.html
We miss the GNU LD variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
Cary Coutant ccoutant at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #24 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26
23:32:17 UTC ---
Author: ccoutant
Date: Mon Sep 26 23:32:13 2011
New Revision: 179220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179220
Log:
PR lto/47247
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-27
17:35:27 UTC ---
Carry,
is there any chance to move ahead on this problem? I see you posted the
PREVAILING_DEF_IRONLY_EXP but it was never committed.
Concerning Rafael's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #18 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-16 16:14:52 UTC ---
I have created a small test of the symbol table problem. It is in
http://people.mozilla.com/~respindola/test.tar.xz
The test is
39339456 libxul1.so
34436696 libxul2.so
Yep, it seems similar to what I was getting. Quite important difference and
all the stuff
gets loaded into memory at startup by dynamic linker.
For a 5 MB reduction I might end up writing a wrapper that runs ld twice :-)
You might try GNU-ld's plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #19 from Jan Hubicka hubicka at ucw dot cz 2011-02-16 23:12:32
UTC ---
39339456 libxul1.so
34436696 libxul2.so
Yep, it seems similar to what I was getting. Quite important difference and
all the stuff
gets loaded into memory at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #20 from ccoutant at google dot com 2011-02-16 23:35:28 UTC ---
I have created a small test of the symbol table problem. It is in
http://people.mozilla.com/~respindola/test.tar.xz
The test is firefox's libxul with most files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #21 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-17 01:13:35 UTC ---
Most of it is in the string table. Ian gave me some pointers and I will try to
fix it tomorrow :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz 2011-02-15 18:49:15
UTC ---
A quick summary to see if got this right:
Yes, the summary seems right.
Note that GCC plays now games with not putting COMDATs into LTO symbol table
unless they
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #14 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-15 19:39:09 UTC ---
Sorry, can you expand on what gcc was doing that was causing it to expand the
dynamic symbol table?
With LLVM what we are doing is
*)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz 2011-02-15 23:20:40
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #14 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-15 19:39:09 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #16 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-16 04:03:36 UTC ---
The problem is with dropping linkonce_odr that has been previously reported.
This way gold will allocate entry in the dynamic symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2011-02-16 07:50:48
UTC ---
I see. Even with PREVAILING_DEF_IRONLY_EXP we still have to update gold to
drop
those, no? Gold doesn't know the language semantics to know which visible
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #12 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 2011-02-14 19:59:22 UTC ---
A quick summary to see if got this right:
Currently the linker has three options for a symbol in a comdat:
*) pick one not in the IL.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-10 17:02:02
UTC ---
Do we have a small testcase to experiment with?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-10 17:04:30
UTC ---
Can we mark the symbol COMDAT when we generate the output?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-01-10 17:10:52 UTC
---
Can we mark the symbol COMDAT when we generate the output?
What symbol and what output?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-10 17:13:46
UTC ---
(In reply to comment #4)
Can we mark the symbol COMDAT when we generate the output?
What symbol and what output?
Honza
I don't think hjl/lto-mixed branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
17:54:51 UTC ---
The plugin specification says that once the COMDAT is marked PREVAILING, it has
to be output.
Any symbol marked PREVAILING_DEF must be defined in one object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-01-10 18:26:00
UTC ---
(In reply to comment #6)
The plugin specification says that once the COMDAT is marked PREVAILING, it
has
to be output.
Any symbol marked PREVAILING_DEF must
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
Cary Coutant ccoutant at gcc dot gnu.org changed:
What|Removed |Added
CC||ccoutant at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #9 from Cary Coutant ccoutant at gcc dot gnu.org 2011-01-10
19:07:54 UTC ---
I've added a new disposition code LDPR_PREVAILING_DEF_IRONLY_EXP and a new
version of the GET_SYMBOLS interface to the API specification on the wiki:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
20:56:23 UTC ---
What undesirable things may happen if we mark a COMDAT symbol
PREVAILING_DEF? Is that we won't know which one will be used
if both LTO and non-LTO objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2011-01-10 21:01:55
UTC ---
(In reply to comment #10)
What undesirable things may happen if we mark a COMDAT symbol
PREVAILING_DEF? Is that we won't know which one will be used
if both
35 matches
Mail list logo
