This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
- From: "trippels at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 09 Jan 2014 20:12:12 +0000
- Subject: [Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
- Auto-submitted: auto-generated
- References: <bug-59469-4 at http dot gcc dot gnu dot org/bugzilla/>
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)