http://sourceware.org/bugzilla/show_bug.cgi?id=12944
Summary: GNU LD incorrectly optimize away COMDAT sections
refered from data sections.
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
http://sourceware.org/bugzilla/show_bug.cgi?id=13227
Bug #: 13227
Summary: GCC now produce slim LTO files. Those can't be
linked/archived or nm w/o plugin used. It would be
useful to output diagnostics when user attempts so
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
Bug #: 13229
Summary: V2 of getsymbol linker plugin interface is not
supported by GNU LD
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
http://sourceware.org/bugzilla/show_bug.cgi?id=13230
Bug #: 13230
Summary: IRONLY_EXP incorrectly reported as IRONLY by gold when
fat LTO files are used
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
http://sourceware.org/bugzilla/show_bug.cgi?id=13230
--- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-28
00:01:51 UTC ---
Sorry, the testcas is bogus.
I am however tracking down reason why when building libxul the resolution file
of slim LTO looks like:
1278 96914ca3
http://sourceware.org/bugzilla/show_bug.cgi?id=13230
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
Bug #: 13244
Summary: GNU LD incorrectly complain about undefined hidden
symbols with LTO
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity:
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
15:19:27 UTC ---
OK,
I now understand the problem. It is partly GNU LD issue.
What happens is
1) nsGNOMEShellService includes header that define gfxUnknownSurface
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
Bug #: 13245
Summary: PREVAILING_DEF reported too often.
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
15:51:57 UTC ---
I was wrong about .h trickery. It is default visibility in both libraries, but
because libxul do not link with any library that would (mistakely) export
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
15:55:21 UTC ---
Note that this blocks mozilla build with -flto -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--
Configure bugmail: http
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-06
19:09:55 UTC ---
Hmm, reproducing the situation is harder with the COMDAT hack in your compiler.
Here is testcase that reproduces w/o GCC patch.
With BFD and patch for V2
http://sourceware.org/bugzilla/show_bug.cgi?id=15270
Bug #: 15270
Summary: GNU LD produce stale dynamic table entries for symbols
optimized out by LTO
Product: binutils
Version: unspecified
Status: NEW
http://sourceware.org/bugzilla/show_bug.cgi?id=15469
Bug #: 15469
Summary: GNU LD incorrectly binds weakref to a random symbol
when weakref target is taken away by linker plugin
Product: binutils
Version: unspecified
http://sourceware.org/bugzilla/show_bug.cgi?id=14342
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Compiling C hello word gets into 2072 bytes of stripped binary with -flto
-fuse-linker-plugin, wile it is 1882 with -flto -fno-use-linker-plugin. Seems
to be difference in dyn* and hash* sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18178
--- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org ---
The corresponding GCC bug is currently P2 regression in 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--
You are receiving this mail because:
You are on the CC list
https://sourceware.org/bugzilla/show_bug.cgi?id=19317
Jan Hubicka changed:
What|Removed |Added
Blocks||18178
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=19317
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Jan Hubicka
https://sourceware.org/bugzilla/show_bug.cgi?id=18178
Jan Hubicka changed:
What|Removed |Added
Depends on||19317
--- Comment #2 from Jan Hubicka
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Hi,
the implementation of IL linking in GCC is currently
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The following code:
https://sourceware.org/bugzilla/show_bug.cgi?id=19498
Jan Hubicka changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://sourceware.org/bugzilla/show_bug.cgi?id=19498
--- Comment #2 from Jan Hubicka ---
This works only when the alias target is known to bound to current def. If it
is global symbol, I think we need gas accept the sources.
I however implemented the optimization to GCC now.
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=23079
--- Comment #3 from Jan Hubicka ---
Thanks for isolating this! The diagnostics is new in GCC 8. We may silence it
if we agree that choosing random prevailing variant is way to go.
Honza
--
You are receiving this mail because:
You are on
https://sourceware.org/bugzilla/show_bug.cgi?id=24083
--- Comment #2 from Jan Hubicka ---
Created attachment 11529
--> https://sourceware.org/bugzilla/attachment.cgi?id=11529=edit
ordering file
I am attaching the ordering file. I just spoke with HHVM developers and they
say that they had
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hubicka at gcc dot gnu.org
CC: ian at airs dot com
Target Milestone: ---
HHVM uses
--section-ordering-file,/aux/hubicka/hhvm/hphp/hhvm/../tools/oss_hot_section_ordering,
which makes gold to link
https://sourceware.org/bugzilla/show_bug.cgi?id=25295
--- Comment #1 from Jan Hubicka ---
I was looking into the problem bit more. We want to support
__attribute__((symver("foo@VERS_1"))
int foo()
{
}
which will export foo as foo@VERS_1. I would also like things like calling foo
work as
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I.e. in testcase attached to
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01179.html
we get:
1
foo.o 4
205 dc8dc21a4ac8d072
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
GCC now support symver attribute. However in order to make
.symver sym, name@nodename
to work, sym needs
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
jan@skylake:~> cat t.c
#define def(name) struct name {int name;} name;
#define def2(name) def(n
https://sourceware.org/bugzilla/show_bug.cgi?id=25295
--- Comment #3 from Jan Hubicka ---
self contained testcase is in comment #1.
Compiling it leads to following assembly:
.file "t.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
32 matches
Mail list logo
