This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

An egcs (gcc) bug with static objects


Hello,

I think I've found a bug in egcs (gcc) concerning the destruction
order of static objects.

I short, ISO C++ standard says that objects of static storage duration
(declared at block scope or at namespace scope) are destroyed (and
their destructor called) "in the reverse order of the completion of
their constructor". (3.6.3 1)

However, it seems this is not always the case with egcs, even in the
latest snapshot I tried (19990718).

Here's a test file:

----------------------- test2.cc -------------------------
#include <iostream>

class S
{
public:
  S();
  ~S();
};

S::S() { cerr << "S::S()" << endl; }
S::~S() { cerr << "S::~S()" << endl; }

void staticS()
{
  static S s;
}

class X
{
public:
  X();
  ~X();
};

X::X()
{
  cerr << "X::X()..." << endl;
  staticS(); // The static S object gets constructed here
  cerr << "...X::X()" << endl;
}
X::~X() { cerr << "X::~X()" << endl; }

static X x;

int main()
{
  cerr << "main()" << endl;
}
----------------------- test2.cc -------------------------

When the program is executed, it displays the following:

X::X()...
S::S()
...X::X()
main()
S::~S()
X::~X()

The static S object is constructed inside the static X object's
constructor, meaning that the constructors are completed in the order
S first, then X. However, the destructors for these objects are _not_
executed in _reverse_ order.

My guess is that this happens because S is a static declared at block
scope whereas X is a static declared at (global) namespace
scope. However, the standard does not seem to think that it matters.


Here is the command I used to compile the program, with the -v option:

Reading specs from /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/specs
gcc version 2.95 19990718 (prerelease)
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -W -Wall -pedantic -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ test2.cc /tmp/ccvMznoX.ii
GNU CPP version 2.95 19990718 (prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/../../../../include/g++-3
 /usr/local/include
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/../../../../i686-pc-linux-gnu/include
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/cc1plus /tmp/ccvMznoX.ii -quiet -dumpbase test2.cc -W -Wall -pedantic -version -o /tmp/ccSlj4fM.s
GNU C++ version 2.95 19990718 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 2.95 19990718 (prerelease).
 as -V -Qy -o /tmp/cc3KyOUR.o /tmp/ccSlj4fM.s
GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23
 /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/collect2 -rpath /usr/local/egcs-990719/lib -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/crtbegin.o -L/usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95 -L/usr/local/egcs-990719/lib /tmp/cc3KyOUR.o -lstdc++ -lm -lgcc -lc -lgcc /usr/local/egcs-990719/lib/gcc-lib/i686-pc-linux-gnu/2.95/crtend.o /usr/lib/crtn.o


I'm running egcs on a Linux Redhat 6.0 box. When I compiled egcs, I
used configure options

--prefix=/usr/local/egcs-990719 --enable-shared --with-cpu=i686
--enable-cpp --enable-languages=c++,java


I hope that's enough information for a bug report. If not, I'm happy
to provide more information.

------------ Matti Rintala ----------- bitti@cs.tut.fi ------------
"Your reality, sir, is lies and balderdash and I'm delighted to say
that I have no grasp of it whatsoever."
 (Baron von Münchausen in "The Adventures of Baron von Münchausen")


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]