http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #52 from Markus Trippelsdorf <trippels at gcc dot gnu.org> --- (In reply to Jason Merrill from comment #51) > (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? Sorry, I've forgot to mention that my system binutils use the linker plugin by default. So you have to use the gcc wrapper (gcc-nm) to read the lto symbols, like: gcc -c -flto wa.C -O2 -v && gcc-nm wa.o
