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
Severity
http://sourceware.org/bugzilla/show_bug.cgi?id=15300
Bug #: 15300
Summary: AR/NM/GNU LD and Gold should issue a warning when used
on objects with GCC/LLVM LTO data in it and no other
symbols
Product: binutils
Ver
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
Sta
http://sourceware.org/bugzilla/show_bug.cgi?id=15516
Bug #: 15516
Summary: GNU LD is confused when linker plugin turns COMDAT
symbol into static w/o renaming.
Product: binutils
Version: unspecified
Status: NEW
http://sourceware.org/bugzilla/show_bug.cgi?id=14342
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
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
: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hubicka at gcc dot gnu.org
CC: ian at airs dot com
Hello,
there seems to be 3 answers to what should be incremntal linking with LTO
1) incremental linker should
https://sourceware.org/bugzilla/show_bug.cgi?id=18178
--- Comment #1 from Jan Hubicka ---
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 for the bug.
_
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
https://sourceware.org/bugzilla/show_bug.cgi?id=18178
Jan Hubicka changed:
What|Removed |Added
Depends on||19317
--- Comment #2 from Jan Hubicka
https://sourceware.org/bugzilla/show_bug.cgi?id=19317
Jan Hubicka changed:
What|Removed |Added
Blocks||18178
Referenced Bugs:
https://source
https://sourceware.org/bugzilla/show_bug.cgi?id=19317
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Jan Hubicka --
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 co
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 receiv
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=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 the
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=24083
--- Comment #2 from Jan Hubicka ---
Created attachment 11529
--> https://sourceware.org/bugzilla/attachment.cgi?id=11529&action=edit
ordering file
I am attaching the ordering file. I just spoke with HHVM developers and they
say that they ha
: 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 to be
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 expec
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(name
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:
http://sourceware.org/bugzilla/show_bug.cgi?id=12942
Summary: Plugin not handling correctly resolution of COMDATs.
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assign
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
Priori
http://sourceware.org/bugzilla/show_bug.cgi?id=12944
Jan Hubicka changed:
What|Removed |Added
CC||dave.korn.cygwin at gmail
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
Severi
http://sourceware.org/bugzilla/show_bug.cgi?id=13230
--- Comment #1 from Jan Hubicka 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 RESOLVED_IR
_ZN21nsDependentCSubstrin
http://sourceware.org/bugzilla/show_bug.cgi?id=13230
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Component|gold
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: normal
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #9 from Jan Hubicka 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.
The class is obviously uunused
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 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 it,
it gets optimized out the
http://sourceware.org/bugzilla/show_bug.cgi?id=13245
--- Comment #1 from Jan Hubicka 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://sourceware.org/bugzilla/userprefs.cg
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #14 from Jan Hubicka 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 API:
jh@evans:/abuild/jh/t
37 matches
Mail list logo
