[Bug lto/53831] Inline virtuals missing in LTO symtab

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-03 10:59:57 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > I don't think linker can do much after gcc removes the symbol from symtab.
> 
> I belive the contract between the linker and GCC is that GCC can introduce
> new references to externally visible symbols and remove references and
> defs of symbols that are only used from inside the executable (the linker
> tells GCC that fact).  The question is who is at fault here - GCC doing
> something it may not do or the linker not handling a situation it should
> handle.

That is, the linker tells us (-v -save-temps, grab the -fresolution= filename
from the lto1 -fwpa invocation):

repro> cat -- -lm.res
2
main.o 4
208 7b62d4c061a2d132 PREVAILING_DEF main
193 7b62d4c061a2d132 RESOLVED_IR _ZN1C1gEv
204 7b62d4c061a2d132 UNDEF _ZN1C1fEv
180 7b62d4c061a2d132 RESOLVED_IR _ZTV1C
libdummy.a@0xbc 2
164 84325c9d3f031d4d PREVAILING_DEF_IRONLY _ZN1C1gEv
184 84325c9d3f031d4d PREVAILING_DEF_IRONLY _ZTV1C

so _ZN1C1gEv is not referenced from outside the link target.  So GCC
removes it and (hopefully!) all references.  And I cannot see any
references to _ZN1C1gEv in the final assembler file, but only the
version that was brought local (_ZN1C1gEv.2356 in my case).

So it does look like a linker issue after all.