Re: bug in g++ 2.7.2.f.1

Re: bug in g++ 2.7.2.f.1

[Craig Chambers]

I've verified that the bug exists in a number of 2.7.2.1 g++ compilers for
different architectures available to me (PowerPC, Linux/x86, Alpha), but I
found a 2.8.1 g++ on Linux, and the bug appears to be corrected for that g++
version (at least for my small test case).

-- Craig Chambers

Re: bug in g++ 2.7.2.f.1

[Alexandre Oliva]

Craig Chambers <chambers@cs.washington.edu> writes:

> I believe I've found a bug in g++ version 2.7.2.f.1 compiling on and
> for an UltraSparc running Solaris.


> The expected output is 4 pairs of "constructed"/"destructed" lines, but
> for the two calls to "broken" with non-zero arguments, the "destructed"
> line doesn't appear.

I can't reproduce your problem with neither gcc-2.7.2.3+g77-0.5.23,
egcs 1.0.3 nor the latest snapshot of egcs, on sparc-sun-solaris2.5,
so I believe the problem was fixed already.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

bug in g++ 2.7.2.f.1

[Craig Chambers]

I believe I've found a bug in g++ version 2.7.2.f.1 compiling on and
for an UltraSparc running Solaris.  (I don't know if local modifications
were made to the source, as I didn't do the installation myself.)

The bug appears to involve an interaction between local class objects with
destructors and local dynamically sized arrays.  Here is an input
program that has incorrect behavior when compiled with g++, either with
no options or with -O2.

#include <stdio.h>

class Test {
public:
  Test() { printf("constructed\n"); }
  ~Test() { printf("destructed\n"); }
};  

void broken(int size){
    Test test;
    if (size) {
      char buffer[size];
      return; /* forgets to call destructor here! */
    }
}

void main() {
  broken(1);
  broken(0);
  broken(1);
  broken(0);
}


The expected output is 4 pairs of "constructed"/"destructed" lines, but
for the two calls to "broken" with non-zero arguments, the "destructed"
line doesn't appear.

The problem is that Test::~Test isn't being called when the function returns
from the nested block.  If the return is removed, then correct behavior ensues.
If the buffer is statically sized or declared in the outer scope, the bug
disappears also.

Thanks for your help.

-- Craig Chambers