Mark Mitchel's commit to fix PR c++/16405 introduced a miscompilation in Qt. It took me a few weeks to deduce a testcase. testcase is: === Cut === extern "C" void abort( void ); struct A { A() { d = d2 = 0; width = -1; } A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {} A b( const A &r ) const; int d; int d2; int width; }; A A::b( const A &r ) const { A tmp; tmp.width = width < r.width ? width : r.width; return tmp; } int main() { A a( 100 ); a = a.b( A( 10 ) ); if ( a.width != 10 ) abort(); } === Cut === The issue is that the result of "a.b(A (10))" is never copied to a, hence the if() afterwards fails.
Hmm, a = b (&a, &D.1613); I think the problem is that we cannot remove the tempory return value for this testcase. Here is another testcase which is related testcase: extern "C" void abort( void ); struct A { A() { d = d2 = 0; width = -1; } A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {} A b( ) const; int d; int d2; int width; }; A A::b( ) const { A tmp; tmp.width = 10+this->width; return tmp; } int main() { A a( 100 ); a = a.b(); if ( a.width != 110 ) abort(); }
And another one (note on most targets a is passed by reference which is where the problem comes from): extern "C" void abort( void ); struct A { A() { d = d2 = 0; width = -1; } A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {} A b( const A &r ) const; int d; int d2; int width; }; A A::b( const A &r ) const { A tmp; tmp.width = width < r.width ? width : r.width; return tmp; } int main() { A a( 10 ); A b(100); a = b.b( a ); if ( a.width != 10 ) abort(); }
Yes this is defind. As 12.2P1 says: "Temporaries of class types are created in various contexts: ... returning an rvalue (6.6.3) ..." "Even when the creation of the temporary object is avoided (12.8), all semantic restrictions must be respected as if the temporary object was created". So we have to create a temporary variable for this return value in all three of my examples. Hmm, the c example for all three does the correct thing and create a temporary variable.
Also we only remove the temporary variable if the size is "large" which seems wrong. Here is another example and the reason why it works with the C front-end is because we don't do NRV until late: extern "C" void abort( void ); typedef struct A { int width; int width1; int width3; int width5; }A; A bb( const A*this1, const A *r ) { A tmp; tmp.width = -1; tmp.width += this1->width < r->width ? this1->width : r->width; return tmp; } int main() { A a; a.width = ( 10 ); A b; b.width = (100); a = bb( &b, &a ); if ( a.width != 9 ) abort(); }
Jason was looking into NRV issues...
*** Bug 19603 has been marked as a duplicate of this bug. ***
bug has been fixed by 2005-02-13 Jason Merrill <jason@redhat.com> PR mudflap/19319 * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return slot explicit. PR c++/16405 * fold-const.c (fold_indirect_ref_1): Split out from... (build_fold_indirect_ref): Here. (fold_indirect_ref): New fn. * tree.h: Declare it. * gimplify.c (gimplify_compound_lval): Call fold_indirect_ref. (gimplify_modify_expr_rhs): Likewise. (gimplify_expr): Likewise. can anyone add the testcase to the regression testsuite please? it seems to me however the above commit caused another regression, I get other miscompilations now.
(In reply to comment #7) > it seems to me however the above commit caused another regression, I get > other miscompilations now. More than just that it causes a bootstrap to fail (I think you must have just did a build and not a full bootstrap).
bootstrap failure is fixed, and 16405 works too, but this testcase still fails.
Created attachment 8202 [details] reverting Mark Mitchels original fix for 16405 reverting Mark's commit makes 16405 still pass and fixes 19317.
CC'ed.
(In reply to comment #10) > Created an attachment (id=8202) > reverting Mark Mitchels original fix for 16405 > > reverting Mark's commit makes 16405 still pass and fixes 19317. This fix helped a little but misscompilation is still present. Kmail and Knode work perfectly but Konqueror crashes. (gdb) r Starting program: /usr/bin/konqueror Program received signal SIGSEGV, Segmentation fault. 0x40c62654 in QIconSet::~QIconSet () from /usr/lib/libqt-mt.so.3 (gdb) bt #0 0x40c62654 in QIconSet::~QIconSet () from /usr/lib/libqt-mt.so.3 #1 0x08215800 in ?? () #2 0x4058c012 in KAction::containerCount () from /usr/lib/libkdeui.so.4 #3 0xbfffee28 in ?? () #4 0x40673e61 in KGuiItem::~KGuiItem () from /usr/lib/libkdeui.so.4 #5 0xbfffdca4 in ?? () #6 0x40083237 in ?? () from /usr/lib/libkdeinit_konqueror.so #7 0xbfffdca4 in ?? () #8 0xbfffed8c in ?? () (...) I've compiled debug version of kdebase340 with cxxflags: -march=i686 -mtune=pentium4 -fvisibility-inlines-hidden -O1 Qt/kdelibs/kdepim was compiled with cxxflags: -march=i686 -mtune=pentium4 -fvisibility-inlines-hidden -O2 -fomit-frame-pointer -funroll-loops
Created attachment 8376 [details] ugly hack to avoid konqueror crash thats true, I added this crude hack to workaround this crash locally. I'd really would hope to see this bug fixed.. its such a major showstopper for an otherwise mostly working compiler. And users as well as distributors are complaining to KDE about this bug. Even if the real fix takes another few months to figure out, please at least apply my crude hack that makes most of the miscompilations go away.
(In reply to comment #13) > Created an attachment (id=8376) > ugly hack to avoid konqueror crash > > thats true, I added this crude hack to workaround this > crash locally. > > I'd really would hope to see this bug fixed.. its such a major > showstopper for an otherwise mostly working compiler. And users > as well as distributors are complaining to KDE about this bug. Even > if the real fix takes another few months to figure out, please at least > apply my crude hack that makes most of the miscompilations go away. > Hack applied. Now the KDE works fine except arts :/ Program received signal SIGSEGV, Segmentation fault. 0x406a1727 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x406a1727 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x4005b3ba in virtual thunk to Arts::SoundServerV2_stub::version() () from /usr/lib/libsoundserver_idl.so.1 #2 0x4007aa80 in Arts::SampleStorageEntry_base::_IID () from /usr/lib/libsoundserver_idl.so.1 #3 0x08104740 in ?? () #4 0x00000004 in ?? () #5 0x40064c14 in ?? () from /usr/lib/libsoundserver_idl.so.1 #6 0xbffff314 in ?? () #7 0xbffff320 in ?? () #8 0xbffff2d8 in ?? () #9 0x4005bb02 in virtual thunk to Arts::GSLPlayObject_base::_defaultPortsOut() const () from /usr/lib/libsoundserver_idl.so.1 #10 0xbffff320 in ?? () #11 0x08104740 in ?? () #12 0x00000001 in ?? () #13 0xbffff2fc in ?? () #14 0x08161524 in ?? () #15 0x4000d060 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #16 0x4004d23b in Arts::SoundServerStartup_base::_fromString () from /usr/lib/libsoundserver_idl.so.1 gcc4-20050313 + patches for pr18628,19317.
thats the same issue like the konqueror crash which I couldn't find a workaround for in gcc either.
so, we have an unaccaptable g++ at this moment :/
Subject: Re: [4.0/4.1 Regression] removing a temporary return value when we cannot This hack should work around the bug, pending a better fix. *** calls.c.~1~ 2005-02-01 10:53:24.000000000 -0500 --- calls.c 2005-03-17 19:33:38.931587705 -0500 *************** expand_call (tree exp, rtx target, int i *** 1994,2001 **** --- 1994,2003 ---- structure_value_addr = expand_expr (return_arg, NULL_RTX, VOIDmode, EXPAND_NORMAL); } + #if 0 else if (target && MEM_P (target)) structure_value_addr = XEXP (target, 0); + #endif else { /* For variable-sized objects, we must be called with a target
(In reply to comment #15) > thats the same issue like the konqueror crash which I couldn't > find a workaround for in gcc either. > > Please looka at the PR19265 testcase (http://dc.selwerd.nl/dlcrash.tar.bz2). # ./dltest Segmentation fault # gcc -v Reading specs from /usr/lib/gcc/i686-pld-linux/4.0.0/specs Target: i686-pld-linux Configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,ada,java --enable-c99 --enable-long-long --disable-multilib --enable-nls --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x --enable-cmath --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo i686-pld-linux Thread model: posix gcc version 4.0.0 20050319 (prerelease) (PLD Linux)
Using the latest CVS: gcc version 4.0.0 20050324 (prerelease) My reproducer attached to this report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603 is still failing.
*** Bug 20628 has been marked as a duplicate of this bug. ***
Jason -- Please apply the work-around; it's the best we've got at present. Thanks, -- Mark
Subject: Bug 19317 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: jason@gcc.gnu.org 2005-04-05 23:13:35 Modified files: gcc : ChangeLog calls.c Log message: PR c++/19317 * calls.c (expand_call): Disable return slot optimization. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.129&r2=2.7592.2.130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.378&r2=1.378.8.1
Work around applied to the 4.0 branch so this is only 4.1 regression now
(In reply to comment #15) > thats the same issue like the konqueror crash which I couldn't > find a workaround for in gcc either. (gdb) bt #0 ~QIconSet (this=0x8209614) at qshared.h:50 ~QIconSet (this=0x8209614) at qshared.h:50 50 bool deref() { return !--count; } (gdb) print this $1 = (QIconSet * const) 0x8209614 (gdb) print *this $2 = {_vptr.QIconSet = 0x41048ba8, d = 0x5} It looks as if "d" was corrupted in toplevel. #1 0x4068cc51 in ~KGuiItem (this=0xbfffdbe4) at kguiitem.cpp:109 #2 0x400a1ce5 in ~QPair (this=0xbfffdbe4) at konq_mainwindow.cc:3683 #3 0x400727ea in KonqMainWindow::initActions (this=0x812af98) at konq_mainwindow.cc:3922 #4 0x4008b330 in KonqMainWindow (this=0x812af98, initialURL=@0xbfffef84, openInitialURL=false, name=0x29 <Address 0x29 out of bounds>, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [*] xmluiFile=@0x29) at konq_mainwindow.cc:217 ^^^^^^^^^^^^^^^^ #5 0x4009099c in KonqMisc::createBrowserWindowFromProfile (path=@0xbffff294, filename=@0xbffff26c, url=@0xbffff420, args=@0xbffff3f4, forbidUseHTML=false, filesToSelect=@0xbffff3f0, tempFile=false, openURL=true) at konq_misc.cc:152 #6 0x40096bae in kdemain (argc=41, argv=0x29) at konq_main.cc:155 #7 0x080486a2 in main (argc=41, argv=0x29) at konqueror.la.cc:2 [*] KonqMainWindow constructor was called from this context: (...) } else { KConfig cfg( path, true ); cfg.setDollarExpansion( true ); cfg.setGroup( "Profile" ); QString xmluiFile=cfg.readEntry("XMLUIFile","konqueror.rc"); 152: mainWindow = new KonqMainWindow( KURL(), false, 0, xmluiFile ); ^^^^^^^^^^^^ gcc passed 0x29 inplace of these params.
(In reply to comment #24) > (In reply to comment #15) please ignore previous post. gcc passes params in the right way but something is wrong. with the original sourcecode gdb shows stack frame with invalid parameters (name, xmluiFile): #4 0x4008b10c in KonqMainWindow (this=0x812afc0, initialURL=@0xbfffef5c, openInitialURL=false, name=0x2e <Address 0x2e out of bounds>, xmluiFile=@0x2e) at konq_mainwindow.cc:218 if I access xmluiFile at the begin of this cstr, eg. qDebug("name=%p, xmlui=%s", name, xmluiFile.ascii()); gdb will show a stack frame with correct params: #4 0x4008b130 in KonqMainWindow (this=0x812afc0, initialURL=@0xbfffef5c, openInitialURL=false, name=0x0, xmluiFile=@0xbfffef1c) at konq_mainwindow.cc:218 disassembler shows only s/eax/edx/ in several places. is this a gdb-6.3 bug? i give up.
Subject: Re: [4.1 Regression] removing a temporary return value when we cannot Have you tested the 4.0 branch with the temporary fix I applied? Jason
(In reply to comment #26) > Subject: Re: [4.1 Regression] removing a temporary return > value when we cannot > > Have you tested the 4.0 branch with the temporary fix I applied? > > Jason > I applied a temporary fix and Dirk's hack to get konqueror working but misscompilation still exists. I see it on artsd crash and buggy openoffice behaviour (STLport is misscompiled now). Several gcc-snaps ago artsd/stl/openoffice worked fine.
Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 11 Apr 2005 08:59:58 -0000, "pluto at pld-linux dot org" <gcc-bugzilla@gcc.gnu.org> wrote: >> Have you tested the 4.0 branch with the temporary fix I applied? > > I applied a temporary fix and Dirk's hack to get konqueror working but > misscompilation still exists. My patch fixes all the reduced testcases in this PR. If KDE is still broken, I think that's a separate bug and needs testcases. Can you submit another PR? Jason
(In reply to comment #28) > Subject: Re: [4.1 Regression] removing a temporary return > value when we cannot > > On 11 Apr 2005 08:59:58 -0000, "pluto at pld-linux dot org" <gcc-bugzilla@gcc.gnu.org> wrote: > > >> Have you tested the 4.0 branch with the temporary fix I applied? > > > > I applied a temporary fix and Dirk's hack to get konqueror working but > > misscompilation still exists. > > My patch fixes all the reduced testcases in this PR. If KDE is still > broken, I think that's a separate bug and needs testcases. Can you submit > another PR? I've opened the PR20949
there are two more critical miscompilations in branch, popping up 12 and 10 days ago. I'm currently trying to deduce a testcase, but maybe that information already is sufficient to narrow down the faulty patch (which I didn't try yet). currently there is no non-trivial C++ application that isn't miscompiled or doesn't crash right away.
(In reply to comment #11) > CC'ed.
the konqueror startup crash is fixed by: @@ -3716,7 +3716,7 @@ void KonqMainWindow::initActions() m_paActivateNextTab = new KAction( i18n( "Activate Next Tab" ), "tab_next", QApplication::reverseLayout() ? KStdAccel::tabPrev() : KStdAccel::tabNext(), this, SLOT( slotActivateNextTab() ), actionCollection(), "activatenexttab" ); m_paActivatePrevTab = new KAction( i18n( "Activate Previous Tab" ), "tab_previous", QApplication::reverseLayout() ? KStdAccel::tabNext() : KStdAccel::tabPrev(), this, SLOT( slotActivatePrevTab() ), actionCollection(), "activateprevtab" ); - char actionname[15]; + char actionname[16]; for (int i=1;i<13;i++) { sprintf(actionname,"activate_tab_%02d", i); new KAction(i18n("Activate Tab %1").arg(i), 0, this, SLOT(slotActivateTab()), actionCollection(), actionname); so that is mood.
looking at it - the artsd crash is not reproduceable for me. is this one still there?
can we think about retargeting fixing the optimisation for 4.0.1 ?
I'm still seeing the artsd miscompilation with gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything from gcc-4_0-branch upto 13-05-2005 (circa). This is from an arts *client*: Starting program: /home/bernie/src/gfactory/src/gfactory Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x73d000 [Thread debugging using libthread_db enabled] [New Thread -1209042464 (LWP 20182)] unix_connect: can't connect to server (unix:/tmp/mcop-root/beetle_trilan-0cad-4289417b) bernie: here9 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209042464 (LWP 20182)] 0x006359b7 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x006359b7 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x00913fef in __gnu_cxx::__mt_alloc<std::string, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0xbfc1fd38, __p=0x8509c68, __n=1) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ext/mt_allocator.h:746 #2 0x00914029 in std::_Vector_base<std::string, std::allocator<std::string> >::_M_deallocate (this=0xbfc1fd38, __p=0x8509c68, __n=1) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:123 #3 0x00914066 in ~_Vector_base (this=0xbfc1fd38) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:109 #4 0x009140cf in ~vector (this=0xbfc1fd38) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:273 #5 0x00914102 in ~ObjectReference (this=0xbfc1fd2c) at /usr/local/src/kde/arts/mcop/reference.h:48 #6 0x009069ad in Arts::SoundServer_base::_fromString (objectref=@0xbfc1fd90) at soundserver.cc:1452 #7 0x00e1f0aa in arts_backend_init () from /usr/local/kde/lib/libartscbackend.so.0 #8 0xbfc1fd90 in ?? () #9 0x00e258cc in typeinfo name for Sender () from /usr/local/kde/lib/libartscbackend.so.0 #10 0x00000017 in ?? () Previous frame inner to this frame (corrupt stack?)
(In reply to comment #35) > I'm still seeing the artsd miscompilation with > gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything > from gcc-4_0-branch upto 13-05-2005 (circa). A backtrace showing a crash is not a very useful bug report, and probably has nothing to do with this bug report. It might not even be a gcc bug, as the konqueror failure was not. If you can track down the miscompilation, we'd love to hear about it in a new bug report.
(In reply to comment #36) > (In reply to comment #35) > > I'm still seeing the artsd miscompilation with > > gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything > > from gcc-4_0-branch upto 13-05-2005 (circa). > > A backtrace showing a crash is not a very useful bug report, and probably has > nothing to do with this bug report. It might not even be a gcc bug, as the > konqueror failure was not. If you can track down the miscompilation, we'd love to hear about it in a new bug report. My backtrace looks suspiciously similar to the backtrace reported in comment #14. My backtrace is from an arts client, not from the artsd server, but they do share lots of common code. I've tried to debug the problem: something weird happens in the destructor of a vector<string>, then GDB seems to get confused by stack/registers corruption. It really looks like a code generation bug to me. Reducing a testcase isn't trivial, but I'll try.
Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 18 May 2005 20:45:22 -0000, "bernie at develer dot com" <gcc-bugzilla@gcc.gnu.org> wrote: > My backtrace looks suspiciously similar to the backtrace reported in > comment #14. Yep, yours is probably the same bug as that in comment #14, which I don't think is related to the original bug report. 20949 was opened for that bug, then closed for lack of a testcase. > Reducing a testcase isn't trivial, but I'll try. Thanks. If you do come up with one, it probably makes the most sense to attach it to 20949 and reopen it. Jason
(In reply to comment #37) > Reducing a testcase isn't trivial, but I'll try. try to pass to the ./configure the kde_cv_val_gcc_visibility_bug=yes switch. rebuild and test artsd. it may help. currently i have a gcc-4.0.1-20050514(+patches:19664,20218,v3) and artsd works fine without hacks.
(In reply to comment #38) > > My backtrace looks suspiciously similar to the backtrace reported in > > comment #14. > > Yep, yours is probably the same bug as that in comment #14, which I don't > think is related to the original bug report. 20949 was opened for that > bug, then closed for lack of a testcase. Ah, OK. Then I think this bug should be closed: the patch is already applied and the other testcases (comment #1, comment #2 and comment #4) all work for me. > > Reducing a testcase isn't trivial, but I'll try. > > Thanks. If you do come up with one, it probably makes the most sense to > attach it to 20949 and reopen it. Will do. Thanks!
(In reply to comment #39) > (In reply to comment #37) > > > Reducing a testcase isn't trivial, but I'll try. > > try to pass to the ./configure the kde_cv_val_gcc_visibility_bug=yes switch. > rebuild and test artsd. it may help. I ran the acinclude.m4 test manually, and it links fine for me (altough the binary crashes on startup). $ cat < foo.cpp /* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664 */ #include <string> int some_function( void ) __attribute__ ((visibility("default"))); int some_function( void ) { std::string s("blafasel"); return 0; } $ g++ -fPIC -fvisibility-inlines-hidden -O0 -shared foo.cpp -o foo $ ./foo Segmentation fault > currently i have a gcc-4.0.1-20050514(+patches:19664,20218,v3) > and artsd works fine without hacks. I'll try to build with those patches, thanks.
Subject: Bug 19317 CVSROOT: /cvs/gcc Module name: gcc Changes by: jason@gcc.gnu.org 2005-06-23 14:44:21 Modified files: gcc : ChangeLog tree.h calls.c tree-inline.c tree-pretty-print.c gimplify.c tree-nrv.c tree-pass.h tree-optimize.c gcc/cp : ChangeLog semantics.c Added files: gcc/testsuite/g++.dg/opt: nrv9.C Log message: PR c++/19317 Leave the return slot target in the MODIFY_EXPR rather than making it an argument, but only use it if the CALL_EXPR has a flag set. * tree.h (CALL_EXPR_HAS_RETURN_SLOT_ADDR): Rename to CALL_EXPR_RETURN_SLOT_OPT. * calls.c (expand_call): Adjust. * tree-inline.c (expand_call_inline): Adjust. * tree-pretty-print.c (dump_generic_node): Adjust. And set the flag as appropriate. * gimplify.c (gimplify_modify_expr_rhs): Set CALL_EXPR_HAS_RETURN_SLOT_ADDR where the LHS is obviously safe. * tree-nrv.c (execute_return_slot_opt): Set CALL_EXPR_HAS_RETURN_SLOT_ADDR based on escape analysis. * tree-pass.h: Declare pass_return_slot. * tree-optimize.c (init_tree_optimization_passes): Add it. * cp/semantics.c (simplify_aggr_init_expr): Use CALL_EXPR_RETURN_SLOT_OPT, not CALL_EXPR_HAS_RETURN_SLOT_ADDR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9211&r2=2.9212 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.737&r2=1.738 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.389&r2=1.390 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.196&r2=1.197 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-pretty-print.c.diff?cvsroot=gcc&r1=2.63&r2=2.64 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.136&r2=2.137 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-nrv.c.diff?cvsroot=gcc&r1=2.7&r2=2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-pass.h.diff?cvsroot=gcc&r1=2.42&r2=2.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.108&r2=2.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4797&r2=1.4798 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.477&r2=1.478 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/nrv9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed.
Subject: Bug 19317 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-rhl-branch Changes by: jakub@gcc.gnu.org 2005-07-08 14:13:13 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr19317-1.C pr19317-2.C pr19317-3.C Log message: PR c++/19317 * g++.dg/opt/pr19317-1.C: New test. * g++.dg/opt/pr19317-2.C: New test. * g++.dg/opt/pr19317-3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.5084.2.9.2.37&r2=1.5084.2.9.2.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19317-1.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19317-2.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr19317-3.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=NONE&r2=1.1.2.1
Whilst this bug has been marked as resolved, I am still experiencing the same problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1). My gcc version info : gcc (GCC) 4.1.0 20050924 (experimental) The following is the stack dump for the problem: ------------------------------- Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209124384 (LWP 31570)] [KCrash handler] #4 0x0034ffe3 in __gnu_cxx::__pool<true>::_M_reclaim_block (this=0xa91b20, __p=0x84e6378 "\234�\b�\b�N\b", __bytes=4) at ../../.././libstdc++-v3/src/mt_allocator.cc:254 #5 0x00a71f37 in __gnu_cxx::__mt_alloc<std::string, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/ext/mt_allocator.h:711 #6 0x00a71f71 in std::_Vector_base<std::string, std::allocator<std::string> >::_M_deallocate (this=0xbfc15838, __p=0x84e6378, __n=1) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:129 #7 0x00a71fae in ~_Vector_base (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:115 #8 0x00a72017 in ~vector (this=0xbfc15838) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_vector.h:268 #9 0x00a7204a in ~ObjectReference (this=0xbfc1582c) at ../mcop/core.h:117 #10 0x00a5adc7 in Arts::SoundServerStartup_base::_fromString ( objectref=@0xbfc158d0) at soundserver.cc:2545 #11 0x08067572 in SoundServerStartup (this=0xbfc158b0, r=@0xbfc158b8) at soundserver.h:1376 #12 0x08066b83 in Arts::SoundServerStartup_impl::cleanReference ( this=0x853e6f8) at soundserverstartup_impl.cc:54 #13 0x08066cc1 in Arts::SoundServerStartup_impl::lock (this=0x853e6f8) at soundserverstartup_impl.cc:78 #14 0x08062bf9 in Arts::SoundServerStartup::lock (this=0xbfc15a58) at soundserver.h:2082 #15 0x080624ac in main (argc=14, argv=0xbfc15b74) at artsd.cc:293 ------------------------------- My gcc was installed by: ------------------------------- export CVS_RSH=ssh export CVSROOT=":ext:anoncvs@savannah.gnu.org:/cvsroot/gcc" cvs -z9 checkout -P gcc wwwdocs cd gcc ./configure make -j 2 make install ------------------------------- I have peformed a random check of the patches in Remark #42 below and they seem to be in the source I've downloaded.
Kevin, can you try out the various testcases from this report and see whether your compiler fails any of them? W.
All three testcases compile & run ok.
Then the issue you are seeing is a separate one, and we would need to have a smaller testcase to figure out what is going on. Please try to work on finding one so that we can look at it. Thanks Wolfgang
A discussion on another mailing list revealed the page http://lists.kde.org/?l=kde-devel&m=112537321024777&w=2 where it states that the bug is in libstdc++ and can be overcome by setting the environment variable GLIBCXX_FORCE_NEW. Obviously, this is a work-around until the real problem is fixed. So, indeed, the problem I reported is not due to the bug described in the Report. Thx for your help.
Subject: Bug 19317 Author: jakub Date: Thu Dec 8 21:50:38 2005 New Revision: 108247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108247 Log: PR c++/19317 * g++.dg/opt/pr19317-1.C: New test. * g++.dg/opt/pr19317-2.C: New test. * g++.dg/opt/pr19317-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr19317-1.C trunk/gcc/testsuite/g++.dg/opt/pr19317-2.C trunk/gcc/testsuite/g++.dg/opt/pr19317-3.C Modified: trunk/gcc/testsuite/ChangeLog
Subject: Bug 19317 Author: jakub Date: Thu Dec 8 21:56:44 2005 New Revision: 108253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108253 Log: PR c++/19317 * g++.dg/opt/pr19317-1.C: New test. * g++.dg/opt/pr19317-2.C: New test. * g++.dg/opt/pr19317-3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-3.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog