[Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test

["dave.anglin at bell dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692

--- Comment #11 from dave.anglin at bell dot net 2011-10-11 14:18:52 UTC ---
On 10/11/2011 9:08 AM, jason at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
>
> --- Comment #10 from Jason Merrill<jason at gcc dot gnu.org>  2011-10-11 13:08:19 UTC ---
> Namespace-scope objects aren't the problem; we've always handled them fine.
> The problem is with function-local statics, which aren't constructed until the
> function is called, so we can't determine the order of construction at compile
> time.  We need to use atexit for them, and so for proper interleaving of
> destructors we need to use atexit for namespace-scope objects as well, but that
> can cause trouble with dlclose, which is why we created __cxa_atexit.
I understand this point.  We don't use atexit on PA-RISC HP-UX for 
namespace-scope
objects.  On 32-bit HP-UX 11, we use a linker option to register 
initializer and finalizer
routines for each executable and shared library.  Thus, we don't have a 
problem
with dlclose for namespace-scope objects.

The problem is in using atexit for the function-local statics.  
Currently, collect2 builds
a fixed list of destructors for namespace scope objects.  Instead, what 
I'm suggesting
is building the list of destructors dynamically for executables and 
shared libraries.
The namespace-scope and function-local statics would be merged into one 
list that
would be processed by the finalizer for the object.

For systems that need to use atexit, I'm not sure whether this is worth 
the effort.  The
dlclose problem would remain.  I'm not sure that destructor order would 
be deterministic
in a multithreaded application.

Dave