This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
- From: "trippels at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 19 Mar 2014 17:13:11 +0000
- Subject: [Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
- Auto-submitted: auto-generated
- References: <bug-60566-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566
--- Comment #8 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #7)
> (In reply to Markus Trippelsdorf from comment #4)
> > part.ii is part of a library called libkparts.so.4.12.3.
> > When I compile part.cpp with a compiler before r208573 and link the
> > library (all other objects files for the lib are unchanged) and then install
> > the library to my system /usr/lib folder, Okular starts and works fine.
> >
> > If I compile part.cpp with a compiler _after_ r208573 and link the
> > library and install it, Okular shows a popup "Unable to find the Okular
> > component".
>
> Just to be clear, you've tested specifically 208572 vs 208573? Recompiling
> just that one file?
Yes. I compile kdelibs with 208573 and recompile that single file with
208572 and this fixes the issue.
(I also have to revert r208556 in both cases, otherwise kdelibs won't compile).
> > Looking at the library, the only difference are four additional
> > symbols in the good version:
> >
> > _ZThn16_N6KParts13ReadWritePartD0Ev
> > _ZThn16_N6KParts13ReadWritePartD1Ev
> > _ZTv0_n24_N6KParts13ReadWritePartD0Ev
> > _ZTv0_n24_N6KParts13ReadWritePartD1Ev
>
> These are thunks to the destructor, which are unneeded if the (constructor)
> vtable doesn't refer to them anymore.
>
> (In reply to Jakub Jelinek from comment #5)
> > So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and
> > 4 thunks to those, and see if they are ever called during the startup of
> > Okular?
>
> Or with part_bad, put a breakpoint on __cxa_pure_virtual?
Not much luck with breakpoints thus far.