This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #25 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Rafael Avila de Espindola from comment #24)
> (In reply to Jan Hubicka from comment #22)
> > 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 would thus say that libLLVMAsmParser.s misses the explicit instantiation
> > in it?
> 
> It looks like the expected/correct result is for libLLVMAsmParser.so to have
> an undefined reference that is satisfied by a definition in libLLVMCore.so.
> The definition should come from an explicit template instantiation in
> Function.cpp.
> 
> Markus, do you see the definition in Function.o? What about libLLVMCore.so?

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).

Honza says it is an error to have the symbol undefined in libLLVMAsmParser.so.
(The undefined symbol comes from LLParser.cpp)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]