Re: optimization/5841: g++ calls ctors/dtors in wrong order

[Rasmus Hahn <rassahah at infonie dot de>]

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

From: Rasmus Hahn <rassahah@infonie.de>
To: rodrigc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, rassahah@infonie.de, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/5841: g++ calls ctors/dtors in wrong order
Date: Thu, 7 Mar 2002 16:12:07 +0100

 On Thu, Mar 07, 2002 at 01:31:45AM -0000, rodrigc@gcc.gnu.org wrote:
 > Synopsis: g++ calls ctors/dtors in wrong order
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: rodrigc
 > State-Changed-When: Wed Mar  6 17:31:45 2002
 > State-Changed-Why:
 >     If I compile your program with gcc 3.0.4, I can reproduce
 >     your problem:
 >     
 >     constructed 0xbffff730
 >     constructed 0xbffff700
 >     0xbffff700 destructed
 >     constructed 0xbffff720
 >     constructed 0xbffff700
 >     0xbffff700 destructed
 >     0xbffff720 destructed
 >     0xbffff730 destructed
 
   There is no real problem in the lines above, because every object is
   destructed after its constructed. Did you use optimization?
 
 >     
 >     Compiling your program with gcc 3.1 20020302 (prerelease)
 >     I get:
 >     
 >     constructed 0xbffff730
 >     constructed 0xbffff720
 >     constructed 0xbffff6f0
 >     constructed 0xbffff710
 >     0xbffff710 destructed
 >     0xbffff6f0 destructed
 >     0xbffff720 destructed
 >     0xbffff730 destructed
 >     
 >     Does this look better?
 
   This looks definitely better, but: I got gcc 3.1 20020304 (prerelease)
   in a .tgz package (i didnt find 20020302 and i
   thought it doesnt that much difference) with the result below:
   (reftest.cc is the program from the bug report #5841);
   (comments with #, other lines from shell);
 
   $ g++ reftest.cc 
   $ ./a.out 
   constructed 0xbffff8d4
   constructed 0xbffff8a4
   constructed 0xbffff8c4
   constructed 0xbffff894
   0xbffff894 destructed
   0xbffff8c4 destructed
   0xbffff8a4 destructed
   0xbffff8d4 destructed
 # everything ok though 4 objects are allocated, where gcc-3.0.4 uses only 3
 # but that isnt much loss.
   $ g++ reftest.cc -O
   $ ./a.out 
   constructed 0xbffff8d4
   constructed 0xbffff8b4
   constructed 0xbffff8c4
   constructed 0xbffff8a4
   0xbffff8a4 destructed
   0xbffff8c4 destructed
   0xbffff8d4 destructed
 # Hm, 4 objects constructed, but only 3 objects destructed, which is quite
 # incorrect. Looks like the original error moved into some other problem.
 # However this is only critical if there are some other resources are
 # associated with the temporary objects, eg dynamic memory. Then the missing
 # destructor call results in a resource leak.
   $ g++ -v
   Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
   Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-threads
   Thread model: posix
   gcc version 3.1 20020304 (prerelease)
 
   Greetings - Rasmus
 
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5841
 > 
 
 --