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

[Rasmus Hahn]

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
> 

--