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

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org |

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-09 16:00:17 UTC ---
Not sure to understand which is the current status of this. Should it be simply
*skipped* instead of *xfailed* on such targets?

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

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net 2011-10-10 21:18:32 UTC ---
On 9-Oct-11, at 12:00 PM, paolo.carlini at oracle dot com wrote:

> Not sure to understand which is the current status of this. Should  
> it be simply
> *skipped* instead of *xfailed* on such targets?


No objection to skipping test.

I'm thinking that a warning or something better would be nice if  
__cxa_atexit is needed and it isn't enabled.

Dave
--
John David Anglin    dave.anglin@bell.net

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-10 21:45:19 UTC ---
I honestly don't understand how such a warning would look like: like warning
for any snippet of code where destructors could run in an unpredictable order?
I'm adding Jason in CC in case he can imagine something in this area...
otherwise I guess I would ask you or Steve to just change those testcases to be
skipped instead of xfailed and be done with this very old PR.

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

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> 2011-10-11 01:10:08 UTC ---
(In reply to comment #6)
> I honestly don't understand how such a warning would look like: like warning
> for any snippet of code where destructors could run in an unpredictable order?

The compiler could warn about local statics that need destroying on targets
without __cxa_atexit, letting the user know that they will not be run in
reverse order of construction as they ought.

I think these tests should be xfailed, not skipped; this is a case of C++
semantics being violated.

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-11 01:26:59 UTC ---
Ok, thanks for the clarification, the words "cannot pass" somewhere misled me.

By the way, I think we should audit the testsuite about skipping vs xfailing
tests atexit related, I'm pretty sure to have seen the former too.

In any case, I think this BUG per se can be closed as fixed. Implementing that
kind of warning could be a future project...

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

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net 2011-10-11 12:06:25 UTC ---
On 10-Oct-11, at 5:45 PM, paolo.carlini at oracle dot com wrote:

> I honestly don't understand how such a warning would look like: like  
> warning
> for any snippet of code where destructors could run in an  
> unpredictable order?
> I'm adding Jason in CC in case he can imagine something in this  
> area...
> otherwise I guess I would ask you or Steve to just change those  
> testcases to be
> skipped instead of xfailed and be done with this very old PR.


In principle, I believe this could be fixed on 32-bit PA-RISC HP-UX.   
Initializer and finalizer
routines are registered by collect2 for executables and shared  
objects.  So, it should
be possible to run all destructors in reverse order of construction  
even for dynamically
loaded objects.  It's using atexit that's the problem.

64-bit HP-UX is somewhat different.  It uses .init_array/.fini_array  
but again this works
for shared libraries, etc.

Dave
--
John David Anglin    dave.anglin@bell.net

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

[jason at gcc dot gnu.org]

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.

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

[dave.anglin at bell dot net]

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

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

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> 2011-10-11 14:38:42 UTC ---
(In reply to comment #11)
> what I'm suggesting is building the list of destructors dynamically for
> executables and shared libraries.

That sounds a lot like __cxa_atexit.

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-06-05 17:06 -------
Ropening since it was only xfailed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
 GCC target triplet|hppa2.0w-hp-hpux11.11       |non __cxa_exit targets
           Keywords|                            |xfail
         Resolution|FIXED                       |


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

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

[sje at cup dot hp dot com]

------- Comment #2 from sje at cup dot hp dot com  2006-06-05 16:43 -------
The test init5 has been xfailed on platforms where __cxa_atexit is not
implemented.  Without __cxa_atexit, the test cannot pass.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-05-21 05:34 -------
Confirmed, this testcase should be xfailed for targets that don't have
cxa_atexit.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00748.html
is the patch which will xfail it.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|hppa2.0w-hp-hpux11.11       |
   GCC host triplet|hppa2.0w-hp-hpux11.11       |
   Last reconfirmed|0000-00-00 00:00:00         |2006-05-21 05:34:41
               date|                            |


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