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

["jason at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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?