[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

octoploid at yandex dot com gcc-bugzilla@gcc.gnu.org
Mon Dec 16 13:46:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469

--- Comment #21 from Markus Trippelsdorf <octoploid at yandex dot com> ---
(In reply to Jan Hubicka from comment #20)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
> > 
> > --- Comment #17 from Markus Trippelsdorf <octoploid at yandex dot com> ---
> > In the non-lto case one has:
> > lib/libLLVMAsmParser.so:
> > U
> > _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
> 
> I think this is a bug by itself, since the symbol seems to be nonkeyed
> comdat and thus
> every unit that use it should define it.
> 
> > If I understand you correctly, you say that the undefined symbol
> > of lib/libLLVMAsmParser.so is a bug in LLVM.
> 
> I think it is eitehr bug in source (LLVM). Most probably becuase
> libLLVMAsmParser simply omits inline definition in libLLVMAsmParser.so where
> it
> should not or some sort of bug in C++ visibility logic.
> 
> For that we need to figure out how the symbol is defined and used in
> lib/libLLVMAsmParser.so

libLLVMAsmParser.so only uses the declaration:
http://llvm.org/docs/doxygen/html/SymbolTableListTraits_8h_source.html

And not the definition:
http://llvm.org/docs/doxygen/html/SymbolTableListTraitsImpl_8h_source.html



More information about the Gcc-bugs mailing list