[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[trippels at gcc dot gnu.org]

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