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.
