Re: optimization/5006: Multiple temporary objects created on stack in the same location.

Re: optimization/5006: Multiple temporary objects created on stack in the same location.

[Richard Smith]

The following reply was made to PR optimization/5006; it has been noted by GNATS.

From: Richard Smith <richard@ex-parrot.com>
To: <gcc-gnats@gcc.gnu.org>,  <gcc-prs@cc.gnu.org>,  <richard@ex-parrot.com>, 
     <gcc-bugs@gcc.gnu.org>,  <nobody@gcc.gnu.org>
Cc:  
Subject: Re: optimization/5006: Multiple temporary objects created on stack
 in the same location. 
Date: Tue, 19 Mar 2002 12:44:43 +0000 (GMT)

 It looks like this has been fixed on the 3.1 branch... at least the test
 cases that I originally had are now all running happily.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5006
 
 --
 Richard Smith
 

Re: optimization/5006: Multiple temporary objects created on stack in the same location.

[rth]

Synopsis: Multiple temporary objects created on stack in the same location.

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Wed Apr  3 01:21:51 2002
State-Changed-Why:
    Reported fixed for 3.1.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5006

optimization/5006: Multiple temporary objects created on stack in the same location.

[richard]

>Number:         5006
>Category:       optimization
>Synopsis:       Multiple temporary objects created on stack in the same location.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 04 03:26:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Richard Smith
>Release:        3.0.2 (and 3.0.1)
>Organization:
>Environment:
i686-pc-linux-gnu
>Description:
When compiling with -O, the compiler creates a temporary object of type auto_ptr<A> on the stack.  It then overwrites this with a temporary of type A before calling the destructor on the original auto_ptr<A>.  This tries to call ::operator delete() on what it thinks is the heap-allocated pointer owned by the auto_ptr but is actually a string literal owned by A.  Depending on the exact memory layout, a segv sometimes results.
>How-To-Repeat:
Build with -O to duplicate the bug.  A run-time segv (usually) results.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: