http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #47 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:27:05 2014
New Revision: 207589
URL: http://gcc.gnu.org/viewcvs?rev=207589&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #48 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:27:37 2014
New Revision: 207590
URL: http://gcc.gnu.org/viewcvs?rev=207590&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #49 from Jan Hubicka ---
Author: hubicka
Date: Fri Feb 7 02:28:33 2014
New Revision: 207591
URL: http://gcc.gnu.org/viewcvs?rev=207591&root=gcc&view=rev
Log:
PR ipa/59469
* lto-cgraph.c (lto_output_node): Use
symtab_get_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #46 from Jan Hubicka ---
Created attachment 32067
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32067&action=edit
Path I am testing
Hi,
this is patch I am testing. It synchronizes the logic in lto-cgraph.c and
ipa-partition.c
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #45 from Jan Hubicka ---
The bug here is that lto-cgraph.c still checks DECL_COMDAT as a condition if
symbol is duplicated or partitioned. We really need to get the logic into
lto-cgraph.c and use same test at both places... Will do t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #44 from Markus Trippelsdorf ---
diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index da76b10511f0..e47679239d84 100644
--- a/gcc/lto/lto-partition.c
+++ b/gcc/lto/lto-partition.c
@@ -97,7 +97,7 @@ get_symbol_class (sym
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #43 from Markus Trippelsdorf ---
Created attachment 32045
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32045&action=edit
new testcase
r207489 fixes the original issue. Thanks.
But llvm still doesn't build with -flto:
FAILED:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #42 from Markus Trippelsdorf ---
Ah, I see what's wrong. The following patch fixes the issue:
diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index 6b2d488ed090..bc192d0467b3 100644
--- a/gcc/lto/lto-partition.c
+++ b/g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #41 from Markus Trippelsdorf ---
That doesn't fix this bug, because the symbol still gets optimized away with
-O3:
markus@x4 tmp % g++ -flto -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii
markus@x4 tmp % nm a.out | c++filt| gre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #40 from Jan Hubicka ---
Author: hubicka
Date: Tue Feb 4 05:50:18 2014
New Revision: 207449
URL: http://gcc.gnu.org/viewcvs?rev=207449&root=gcc&view=rev
Log:
PR ipa/59469
* lto-symtab.c (lto_cgraph_replace_node, lto_varpool_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #39 from Jan Hubicka ---
Ha, good catch. Forced_by_abi is a flag that needs to be merged. You do not
want to set force_output as your patch does, just forced_by_abi. I will test
the patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #38 from Markus Trippelsdorf ---
So maybe the following patch is enough:
diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index f5f9d1318ee0..bdb536131707 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -57,7 +
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #37 from Markus Trippelsdorf ---
I think the error is that the symbol from the explicit template instantiation
in Function.ii (marked with forced_by_abi) gets merged with the symbol in the
same COMDAT group from BasicBlock.ii. (This sy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jason Merrill changed:
What|Removed |Added
Component|c++ |ipa
--- Comment #36 from Jason Merrill -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #32 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #31)
> OK, the visibility is:
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_traitsIS1_EENS_14ilist_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #31 from Jan Hubicka ---
OK, the visibility is:
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
(transferNodesFromList) @0x7fd527d7ee18
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #30 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #29)
> >
> > That optimization seems invalid. There is a explicit template instantiation
> > definition, so it is valid for other dsos to have an undefined referen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #29 from Jan Hubicka ---
>
> That optimization seems invalid. There is a explicit template instantiation
> definition, so it is valid for other dsos to have an undefined reference.
Can I see the cgraph dump of the unreduced source fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #28 from Markus Trippelsdorf ---
Created attachment 31790
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31790&action=edit
Function.ii reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #27 from Markus Trippelsdorf ---
Created attachment 31789
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31789&action=edit
BasicBlock.ii reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #26 from Rafael Avila de Espindola ---
> Yes, is see the weak symbol both in BasicBlock.o and Function.o.
> However it gets optimized away when I link them with "-flto -O3" into
> libLLVMCore.so (see comment 0).
That optimization seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael.espindola at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #23 from Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #22 from Jan Hubicka ---
00010 // This file implements the stickier parts of the SymbolTableListTraits
class,
00011 // and is explicitly instantiated where needed to avoid defining all this
code
00012 // in a widely used header.
I wou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #21 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> >
> > --- Comment #17 from Markus Trippelsdorf ---
> > In the non-lto case one has:
> > lib/libLLVMAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #20 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
>
> --- Comment #17 from Markus Trippelsdorf ---
> In the non-lto case one has:
> lib/libLLVMAsmParser.so:
> U
> _ZN4llvm21SymbolTableListTraitsINS_10BasicB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #19 from Jan Hubicka ---
> I can't reproduce this.
> What platform is this? What is the command line?
I used x86-64 and you apparently need LTO to trigger it. I used same
commandline
as in original report
g++ -flto-partition=none -fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #18 from Steven Bosscher ---
(In reply to Jan Hubicka from comment #8)
> OK, the unmangled name of symbol is:
> 0004c8c0 T
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #17 from Markus Trippelsdorf ---
In the non-lto case one has:
lib/libLLVMAsmParser.so:
U
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
lib/lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #16 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > Can you try bfd linker, hjl/linux/release/2.24.51.0.2, from
> >
> > https://sourceware.org/git/?p=binutils-gdb.git;a=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #14 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #13 from H.J. Lu ---
(In reply to Markus Trippelsdorf from comment #12)
> (In reply to Jan Hubicka from comment #10)
> > I also saw in past problems with GNU-ld and comdat symbols becoming static
> > while being comdat somewhere else.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #12 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #10)
> I also saw in past problems with GNU-ld and comdat symbols becoming static
> while being comdat somewhere else. Do you use gold or ld? Can you perhaps
> try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #10 from Jan Hubicka ---
I also saw in past problems with GNU-ld and comdat symbols becoming static
while being comdat somewhere else. Do you use gold or ld? Can you perhaps try
to use the other one and see if anything changes?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #8)
> OK, the unmangled name of symbol is:
> 0004c8c0 T
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ili
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #9 from Jan Hubicka ---
LTO-ing libbackend.a into every frontend binary theoretically results in better
code. I did not see numbers on this.
Now I understand what you complain about. LTO build optimizes out the symbol or
makes it stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jan Hubicka changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #8 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #6)
> With -fno-fat-lto-objects we are also faster on SPEC build time and I think
> it should be the case in general. We produce considerably less code and
> most o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #6 from Jan Hubicka ---
With -fno-fat-lto-objects we are also faster on SPEC build time and I think it
should be the case in general. We produce considerably less code and most of
time is spent in the backend. For super large project
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Richard Biener changed:
What|Removed |Added
Keywords||lto
CC|
43 matches
Mail list logo
