* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
@ 2011-10-09 16:00 ` paolo.carlini at oracle dot com
2011-10-10 21:19 ` dave.anglin at bell dot net
` (7 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-10-09 16:00 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
2011-10-09 16:00 ` [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test paolo.carlini at oracle dot com
@ 2011-10-10 21:19 ` dave.anglin at bell dot net
2011-10-10 21:45 ` paolo.carlini at oracle dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: dave.anglin at bell dot net @ 2011-10-10 21:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
2011-10-09 16:00 ` [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test paolo.carlini at oracle dot com
2011-10-10 21:19 ` dave.anglin at bell dot net
@ 2011-10-10 21:45 ` paolo.carlini at oracle dot com
2011-10-11 1:10 ` jason at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-10-10 21:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-10-10 21:45 ` paolo.carlini at oracle dot com
@ 2011-10-11 1:10 ` jason at gcc dot gnu.org
2011-10-11 1:27 ` paolo.carlini at oracle dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: jason at gcc dot gnu.org @ 2011-10-11 1:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-10-11 1:10 ` jason at gcc dot gnu.org
@ 2011-10-11 1:27 ` paolo.carlini at oracle dot com
2011-10-11 12:07 ` dave.anglin at bell dot net
` (3 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-10-11 1:27 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-10-11 1:27 ` paolo.carlini at oracle dot com
@ 2011-10-11 12:07 ` dave.anglin at bell dot net
2011-10-11 13:08 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: dave.anglin at bell dot net @ 2011-10-11 12:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2011-10-11 12:07 ` dave.anglin at bell dot net
@ 2011-10-11 13:08 ` jason at gcc dot gnu.org
2011-10-11 14:20 ` dave.anglin at bell dot net
2011-10-11 14:39 ` jason at gcc dot gnu.org
8 siblings, 0 replies; 13+ messages in thread
From: jason at gcc dot gnu.org @ 2011-10-11 13:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2011-10-11 13:08 ` jason at gcc dot gnu.org
@ 2011-10-11 14:20 ` dave.anglin at bell dot net
2011-10-11 14:39 ` jason at gcc dot gnu.org
8 siblings, 0 replies; 13+ messages in thread
From: dave.anglin at bell dot net @ 2011-10-11 14:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/27692] FAIL: g++.old-deja/g++.other/init5.C execution test
[not found] <bug-27692-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2011-10-11 14:20 ` dave.anglin at bell dot net
@ 2011-10-11 14:39 ` jason at gcc dot gnu.org
8 siblings, 0 replies; 13+ messages in thread
From: jason at gcc dot gnu.org @ 2011-10-11 14:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread