Bug 19317 - [4.1 Regression] removing a temporary return value when we cannot
Summary: [4.1 Regression] removing a temporary return value when we cannot
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P1 critical
Target Milestone: 4.1.0
Assignee: Jason Merrill
URL:
Keywords: wrong-code
: 19603 20628 (view as bug list)
Depends on:
Blocks: 25977 27371
  Show dependency treegraph
 
Reported: 2005-01-07 19:15 UTC by Dirk Mueller
Modified: 2006-09-06 06:01 UTC (History)
13 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 3.4.0 4.0.0
Known to fail:
Last reconfirmed: 2005-01-26 01:31:17


Attachments
reverting Mark Mitchels original fix for 16405 (597 bytes, patch)
2005-02-16 02:06 UTC, Dirk Mueller
Details | Diff
ugly hack to avoid konqueror crash (540 bytes, patch)
2005-03-11 19:35 UTC, Dirk Mueller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Mueller 2005-01-07 19:15:11 UTC
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.
Comment 1 Andrew Pinski 2005-01-07 19:26:28 UTC
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();
}
Comment 2 Andrew Pinski 2005-01-07 19:30:04 UTC
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();
}
Comment 3 Andrew Pinski 2005-01-10 04:52:38 UTC
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.
Comment 4 Andrew Pinski 2005-01-10 05:03:41 UTC
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();
}
Comment 5 Steven Bosscher 2005-01-15 12:45:33 UTC
Jason was looking into NRV issues...
Comment 6 Andrew Pinski 2005-01-24 13:27:13 UTC
*** Bug 19603 has been marked as a duplicate of this bug. ***
Comment 7 Dirk Mueller 2005-02-13 14:59:21 UTC
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.  
 
Comment 8 Andrew Pinski 2005-02-13 15:40:18 UTC
(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).
Comment 9 Dirk Mueller 2005-02-16 02:02:04 UTC
bootstrap failure is fixed, and 16405 works too, but this testcase still 
fails.  
Comment 10 Dirk Mueller 2005-02-16 02:06:44 UTC
Created attachment 8202 [details]
reverting Mark Mitchels original fix for 16405

reverting Mark's commit makes 16405 still pass and fixes 19317.
Comment 11 Pawel Sikora 2005-03-10 23:49:08 UTC
CC'ed. 
Comment 12 Pawel Sikora 2005-03-11 19:29:24 UTC
(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
Comment 13 Dirk Mueller 2005-03-11 19:35:38 UTC
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.
Comment 14 Pawel Sikora 2005-03-16 13:09:26 UTC
(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. 
Comment 15 Dirk Mueller 2005-03-17 17:33:23 UTC
thats the same issue  like the konqueror crash which I couldn't 
find a workaround for in gcc either.  
 
 
Comment 16 Pawel Sikora 2005-03-17 18:22:06 UTC
so, we have an unaccaptable g++ at this moment :/  
Comment 17 Jason Merrill 2005-03-18 00:34:35 UTC
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
Comment 18 Pawel Sikora 2005-03-24 11:07:01 UTC
(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)
Comment 19 Ralf W. Grosse-Kunstleve 2005-03-24 12:46:06 UTC
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.
Comment 20 Andrew Pinski 2005-03-24 21:04:30 UTC
*** Bug 20628 has been marked as a duplicate of this bug. ***
Comment 21 Mark Mitchell 2005-04-05 06:25:43 UTC
Jason --

Please apply the work-around; it's the best we've got at present.

Thanks,

-- Mark
Comment 22 CVS Commits 2005-04-05 23:14:02 UTC
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

Comment 23 Andrew Pinski 2005-04-07 21:01:31 UTC
Work around applied to the 4.0 branch so this is only 4.1 regression now
Comment 24 Pawel Sikora 2005-04-08 13:33:15 UTC
(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.
Comment 25 Pawel Sikora 2005-04-09 02:29:05 UTC
(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.
Comment 26 Jason Merrill 2005-04-11 07:49:05 UTC
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
Comment 27 Pawel Sikora 2005-04-11 08:59:55 UTC
(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.
Comment 28 Jason Merrill 2005-04-11 12:48:27 UTC
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
Comment 29 Pawel Sikora 2005-04-11 14:43:49 UTC
(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
Comment 30 Dirk Mueller 2005-04-12 10:27:35 UTC
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.  
Comment 31 Ismael Juma 2005-04-12 20:01:37 UTC
(In reply to comment #11)
> CC'ed. 
Comment 32 Dirk Mueller 2005-04-13 01:10:43 UTC
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.  
 
 
Comment 33 Dirk Mueller 2005-04-13 01:36:23 UTC
looking at it - the artsd crash is not reproduceable for me. is this one still 
there? 
 
 
Comment 34 Dirk Mueller 2005-04-13 16:57:22 UTC
can we think about retargeting fixing the optimisation for 4.0.1 ? 
 
 
Comment 35 Bernardo Innocenti 2005-05-17 05:40:45 UTC
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?)
Comment 36 Jason Merrill 2005-05-18 19:38:12 UTC
(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.
Comment 37 Bernardo Innocenti 2005-05-18 20:45:18 UTC
(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.
Comment 38 Jason Merrill 2005-05-18 21:17:56 UTC
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
Comment 39 Pawel Sikora 2005-05-19 09:04:26 UTC
(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. 
 
Comment 40 Bernardo Innocenti 2005-05-19 09:45:48 UTC
(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!
Comment 41 Bernardo Innocenti 2005-05-19 10:42:22 UTC
(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.
Comment 42 CVS Commits 2005-06-23 14:44:34 UTC
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

Comment 43 Andrew Pinski 2005-06-24 14:11:43 UTC
Fixed.
Comment 45 Kevin Gilbert 2005-09-26 23:17:48 UTC
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&#65533;\b&#65533;\b&#65533;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. 
Comment 46 Wolfgang Bangerth 2005-09-27 00:44:22 UTC
Kevin, 
can you try out the various testcases from this report and see whether your 
compiler fails any of them? 
 
W. 
Comment 47 Kevin Gilbert 2005-09-27 07:28:26 UTC
All three testcases compile & run ok. 
Comment 48 Wolfgang Bangerth 2005-09-27 14:01:16 UTC
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 
Comment 49 Kevin Gilbert 2005-09-30 01:59:23 UTC
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. 
Comment 50 Jakub Jelinek 2005-12-08 21:50:41 UTC
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

Comment 51 Jakub Jelinek 2005-12-08 21:56:47 UTC
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