kdelibs gets miscompiled with current trunk. Bisection points to r208573. Symptoms of the miscompilation are startup failures of various KDE application, e.g. okular will show a pop-up "Cannot connect to okular component" and hang. Will look deeper tomorrow.
Created attachment 32387 [details] unreduced testcase I've narrowed it down to a single file. Can't say I understand the issue fully yet. Bad: x4 kparts # g++ -c -O2 part.ii && nm part.o | grep N6KParts13ReadWritePartD 0000000000004d50 T _ZN6KParts13ReadWritePartD0Ev 0000000000004d00 T _ZN6KParts13ReadWritePartD1Ev 0000000000004cd0 T _ZN6KParts13ReadWritePartD2Ev Good: x4 kparts # /var/tmp/gcc_test/usr/local/bin/g++ -c -O2 part.ii && nm part.o | grep N6KParts13ReadWritePartD 0000000000004d70 T _ZN6KParts13ReadWritePartD0Ev 0000000000004d00 T _ZN6KParts13ReadWritePartD1Ev 0000000000004cd0 T _ZN6KParts13ReadWritePartD2Ev 0000000000004da0 T _ZThn16_N6KParts13ReadWritePartD0Ev 0000000000004d60 T _ZThn16_N6KParts13ReadWritePartD1Ev 0000000000004d90 T _ZTv0_n24_N6KParts13ReadWritePartD0Ev 0000000000004d50 T _ZTv0_n24_N6KParts13ReadWritePartD1Ev
--- part_good.s 2014-03-19 08:57:10.100342064 +0100 +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 @@ -13466,49 +13466,10 @@ .text .LHOTE151: .section .text.unlikely + .align 2 .LCOLDB152: .text .LHOTB152: - .p2align 4,,15 - .globl _ZTv0_n24_N6KParts13ReadWritePartD1Ev - .type _ZTv0_n24_N6KParts13ReadWritePartD1Ev, @function -_ZTv0_n24_N6KParts13ReadWritePartD1Ev: -.LFB6687: - .cfi_startproc - movq (%rdi), %r10 - addq -24(%r10), %rdi - jmp _ZN6KParts13ReadWritePartD1Ev - .cfi_endproc -.LFE6687: - .size _ZTv0_n24_N6KParts13ReadWritePartD1Ev, .-_ZTv0_n24_N6KParts13ReadWritePartD1Ev - .section .text.unlikely -.LCOLDE152: - .text -.LHOTE152: - .section .text.unlikely -.LCOLDB153: - .text -.LHOTB153: - .p2align 4,,15 - .globl _ZThn16_N6KParts13ReadWritePartD1Ev - .type _ZThn16_N6KParts13ReadWritePartD1Ev, @function -_ZThn16_N6KParts13ReadWritePartD1Ev: -.LFB6688: - .cfi_startproc - subq $16, %rdi - jmp _ZN6KParts13ReadWritePartD1Ev - .cfi_endproc -.LFE6688: - .size _ZThn16_N6KParts13ReadWritePartD1Ev, .-_ZThn16_N6KParts13ReadWritePartD1Ev - .section .text.unlikely -.LCOLDE153: - .text -.LHOTE153: - .section .text.unlikely - .align 2 -.LCOLDB154: - .text -.LHOTB154: .align 2 .p2align 4,,15 .globl _ZN6KParts13ReadWritePartD0Ev @@ -13529,53 +13490,14 @@ .LFE5572: .size _ZN6KParts13ReadWritePartD0Ev, .-_ZN6KParts13ReadWritePartD0Ev .section .text.unlikely -.LCOLDE154: - .text -.LHOTE154: - .section .text.unlikely -.LCOLDB155: - .text -.LHOTB155: - .p2align 4,,15 - .globl _ZTv0_n24_N6KParts13ReadWritePartD0Ev - .type _ZTv0_n24_N6KParts13ReadWritePartD0Ev, @function -_ZTv0_n24_N6KParts13ReadWritePartD0Ev: -.LFB6689: - .cfi_startproc - movq (%rdi), %r10 - addq -24(%r10), %rdi - jmp _ZN6KParts13ReadWritePartD0Ev - .cfi_endproc -.LFE6689: - .size _ZTv0_n24_N6KParts13ReadWritePartD0Ev, .-_ZTv0_n24_N6KParts13ReadWritePartD0Ev - .section .text.unlikely -.LCOLDE155: - .text -.LHOTE155: - .section .text.unlikely -.LCOLDB156: - .text -.LHOTB156: - .p2align 4,,15 - .globl _ZThn16_N6KParts13ReadWritePartD0Ev - .type _ZThn16_N6KParts13ReadWritePartD0Ev, @function -_ZThn16_N6KParts13ReadWritePartD0Ev: -.LFB6690: - .cfi_startproc - subq $16, %rdi - jmp _ZN6KParts13ReadWritePartD0Ev - .cfi_endproc -.LFE6690: - .size _ZThn16_N6KParts13ReadWritePartD0Ev, .-_ZThn16_N6KParts13ReadWritePartD0Ev - .section .text.unlikely ... .section .rodata .align 32 .type _ZZN6KParts13ReadWritePart11setModifiedEbE19__PRETTY_FUNCTION__, @object @@ -18015,8 +17937,8 @@ .quad _ZNK6KParts13ReadWritePart10metaObjectEv .quad _ZN6KParts13ReadWritePart11qt_metacastEPKc .quad _ZN6KParts13ReadWritePart11qt_metacallEN11QMetaObject4CallEiPPv - .quad _ZN6KParts13ReadWritePartD1Ev - .quad _ZN6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZN7QObject5eventEP6QEvent .quad _ZN7QObject11eventFilterEPS_P6QEvent .quad _ZN7QObject10timerEventEP11QTimerEvent @@ -18050,8 +17972,8 @@ .quad 16 .quad -16 .quad _ZTIN6KParts13ReadWritePartE - .quad _ZThn16_N6KParts13ReadWritePartD1Ev - .quad _ZThn16_N6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZN6KParts8PartBase16setComponentDataERK14KComponentData .quad _ZN6KParts8PartBase16setComponentDataERK14KComponentDatab .quad 0 @@ -18070,8 +17992,8 @@ .quad -32 .quad -32 .quad _ZTIN6KParts13ReadWritePartE - .quad _ZTv0_n24_N6KParts13ReadWritePartD1Ev - .quad _ZTv0_n24_N6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZNK13KXMLGUIClient6actionERK11QDomElement .quad _ZNK13KXMLGUIClient16actionCollectionEv .quad _ZNK13KXMLGUIClient13componentDataEv @@ -18137,5 +18059,5 @@ _ZN6KParts4Part25staticMetaObjectExtraDataE: .quad 0 .quad _ZN6KParts4Part18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv - .ident "GCC: (GNU) 4.9.0 20140314 (experimental)" + .ident "GCC: (GNU) 4.9.0 20140318 (experimental)" .section .note.GNU-stack,"",@progbits
(In reply to Markus Trippelsdorf from comment #2) > --- part_good.s 2014-03-19 08:57:10.100342064 +0100 > +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 > - .quad _ZN6KParts13ReadWritePartD1Ev > - .quad _ZN6KParts13ReadWritePartD0Ev > + .quad __cxa_pure_virtual > + .quad __cxa_pure_virtual I have trouble believing this is causing the problem you are seeing; if something were actually calling through this vtable slot it would write "pure virtual method called" to stderr and then terminate.
(In reply to Jason Merrill from comment #3) > (In reply to Markus Trippelsdorf from comment #2) > > --- part_good.s 2014-03-19 08:57:10.100342064 +0100 > > +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 > > - .quad _ZN6KParts13ReadWritePartD1Ev > > - .quad _ZN6KParts13ReadWritePartD0Ev > > + .quad __cxa_pure_virtual > > + .quad __cxa_pure_virtual > > I have trouble believing this is causing the problem you are seeing; if > something were actually calling through this vtable slot it would write > "pure virtual method called" to stderr and then terminate. 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".
(In reply to Markus Trippelsdorf from comment #4) > 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". 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? For the 2 dtors perhaps always look at the caller if it was a direct call or call through vtable?
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
(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? > 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?
(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.
Running nm on all my libs shows: ... kde4/notepadpart.so U _ZThn16_N6KParts13ReadWritePartD0Ev ... kde4/okularpart.so U _ZThn16_N6KParts13ReadWritePartD0Ev ... libkatepartinterfaces.so U _ZThn16_N6KParts13ReadWritePartD0Ev libkatepartinterfaces.so.4 U _ZThn16_N6KParts13ReadWritePartD0Ev libkatepartinterfaces.so.4.12.3 U _ZThn16_N6KParts13ReadWritePartD0Ev ... libktexteditor.so U _ZThn16_N6KParts13ReadWritePartD0Ev libktexteditor.so.4 U _ZThn16_N6KParts13ReadWritePartD0Ev libktexteditor.so.4.12.3 U _ZThn16_N6KParts13ReadWritePartD0Ev So maybe okular and katepart just need to be recompiled? Let me try this.
(In reply to Markus Trippelsdorf from comment #9) > Running nm on all my libs shows: > ... > kde4/notepadpart.so > U _ZThn16_N6KParts13ReadWritePartD0Ev > ... > kde4/okularpart.so > U _ZThn16_N6KParts13ReadWritePartD0Ev > ... > libkatepartinterfaces.so > U _ZThn16_N6KParts13ReadWritePartD0Ev > libkatepartinterfaces.so.4 > U _ZThn16_N6KParts13ReadWritePartD0Ev > libkatepartinterfaces.so.4.12.3 > U _ZThn16_N6KParts13ReadWritePartD0Ev > ... > libktexteditor.so > U _ZThn16_N6KParts13ReadWritePartD0Ev > libktexteditor.so.4 > U _ZThn16_N6KParts13ReadWritePartD0Ev > libktexteditor.so.4.12.3 > U _ZThn16_N6KParts13ReadWritePartD0Ev > > So maybe okular and katepart just need to be recompiled? > Let me try this. So the errors were dlopen errors when trying to load those libraries? BTW, were those shared libraries built by some earlier version of G++ 4.9, or G++ 4.8 (or some older version)?
(In reply to Jakub Jelinek from comment #10) > (In reply to Markus Trippelsdorf from comment #9) > > Running nm on all my libs shows: > > ... > > kde4/notepadpart.so > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > ... > > kde4/okularpart.so > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > ... > > libkatepartinterfaces.so > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > libkatepartinterfaces.so.4 > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > libkatepartinterfaces.so.4.12.3 > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > ... > > libktexteditor.so > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > libktexteditor.so.4 > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > libktexteditor.so.4.12.3 > > U _ZThn16_N6KParts13ReadWritePartD0Ev > > > > So maybe okular and katepart just need to be recompiled? > > Let me try this. > > So the errors were dlopen errors when trying to load those libraries? Recompilation of Okular, katelib and pykde4 fixed the issue. But there were no dlopen errors in the log. Somehow KDE manages to hide them from the user... > BTW, were those shared libraries built by some earlier version of G++ 4.9, > or G++ 4.8 (or some older version)? Yes, there were build with earlier version of 4.9. But this is a nasty issue that will potentially surprise many users of 4.9.
(In reply to Markus Trippelsdorf from comment #11) > > BTW, were those shared libraries built by some earlier version of G++ 4.9, > > or G++ 4.8 (or some older version)? > > Yes, there were build with earlier version of 4.9. > > But this is a nasty issue that will potentially surprise many users of 4.9. I agree it is nasty, but if a released compiler never has exposed such symbols (I assume it could have done that only through bogus? devirtualization), then it is not as bad as if this would be effectively an ABI break from 4.8.
Actually, this is an ABI breakage even without devirtualization: wa.h: struct A { virtual void f() = 0; virtual ~A() {} }; struct B: virtual A { int i; }; struct C: virtual A { int i; ~C(); }; wa.C: #include "wa.h" struct D: B, C { void f(); }; void D::f() {} wa2.C: #include "wa.h" C::~C() { } int main() {} Compiling wa.C with 4.8 and wa2.C with 4.9 results in undefined symbol errors.
Author: jason Date: Wed Mar 26 16:50:26 2014 New Revision: 208845 URL: http://gcc.gnu.org/viewcvs?rev=208845&root=gcc&view=rev Log: PR c++/60566 PR c++/58678 * class.c (build_vtbl_initializer): Handle abstract dtors here. * search.c (get_pure_virtuals): Not here. Added: trunk/gcc/testsuite/g++.dg/abi/thunk6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/search.c trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/g++.dg/ipa/devirt-21.C trunk/gcc/testsuite/g++.dg/ipa/devirt-23.C
Fixed.