http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #51 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Markus Trippelsdorf from comment #48) > markus@x4 /tmp % /var/tmp/gcc_test/usr/local/bin/g++ -flto -c -O2 test.ii && > nm test.o | grep _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE > U _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE Strange. # ggcc -c -flto wa.C -O2 -v && nm wa.o ... GNU C++ (GCC) version 4.9.0 20140317 (experimental) (x86_64-unknown-linux-gnu) ... 0000000000000001 C __gnu_lto_slim 0000000000000001 C __gnu_lto_v1 It seems GCC is defaulting to fat LTO objects for you, but not for me; I guess that's because my system linker supports the LTO plugin. But even compiling with -ffat-lto-objects doesn't reproduce the problem; with that option nm shows 0000000000000001 C __gnu_lto_v1 U _ZN1BIiE14const_iteratorneES1_ U _ZN8Calligra6Sheets1G5m_fn1Ev 0000000000000000 T _ZN8Calligra6Sheets1H5m_fn1Ev U _ZNK8Calligra6Sheets1H5m_fn2Ev U _ZNK8Calligra6Sheets1H5m_fn3Ev And -fdump-ipa-devirt shows that we aren't speculatively devirtualizing a call to ~J because it's an artificial destructor, so it seems to have been fixed by r208241. What does -fdump-ipa-devirt say for you?