http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687
Lassi Tuura <lat at cern dot ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lat at cern dot ch
--- Comment #1 from Lassi Tuura <lat at cern dot ch> 2011-10-11 09:25:24 UTC ---
FWIW, I don't think this is a bug in the compiler. With -fvisibility=hidden a
promise is made that bar::foo() is internal to the shared library, and if the
compiler generates virtual function table for bar, it needs foo too.
At least on a system I tested, RHEL5-derived system with GCC 4.6.1 and binutils
2.21.1 gold as the linker, the reason there's no unreferenced symbols without
-flto is simply that no code what so ever is getting generated for 'bar'. In
fact no code at all is emitted for test.cc. I assume the compiler just decides
the class is irrelevant to the compilation unit, which seems entirely
reasonable choice to me -- otherwise it'd be generating code for loads of types
from headers which are never used in a particular compilation unit.
With 4.6.x LTO presumably this pruning doesn't happen, or isn't complete
enough, and/or isn't garbage collected at link phase as unreferenced, so the
bar::foo reference remains and becomes unsatisfied symbol - which seems
reasonable to me. Perhaps it's a quality issue that unreferenced types cause
code to be generated, but IMHO is not a bug in the compiler.
If I change the code so it forces a reference generated for bar, so the bar
virtual function table gets generated, triggering getFoo() to be compiled, I
get the same undefined symbol without LTO with GCC 4.6.1 too. I didn't try with
GCC trunk, so can't comment on why the reference isn't seen there.
