https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #21 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bd2a59b7b3f049d81566163056ae1206d4fa3e6d
commit r8-10896-gbd2a59b7b3f049d81566163056ae1206d4fa3e6d
Author: Jakub Jelinek
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #20 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cb6efb9d909323e41fa0a8abbe805eb32d1659ea
commit r9-9432-gcb6efb9d909323e41fa0a8abbe805eb32d1659ea
Author: Jakub Jelinek
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #19 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1703937a05b8b95bc29d2de292387dfd9eb7c9a3
commit r10-9487-g1703937a05b8b95bc29d2de292387dfd9eb7c9a3
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0251051db64f13c9a31a05c8133c31dc50b2b235
commit r11-7696-g0251051db64f13c9a31a05c8133c31dc50b2b235
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #17 from Richard Biener ---
I think for the non-dependent case there's no good fix but the standard can be
read in a way that only the dependent case has well-defined order of
destruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #16 from Jakub Jelinek ---
Created attachment 50399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50399&action=edit
gcc11-pr99613.patch
Untested patch that swaps the two calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jake Hemstad changed:
What|Removed |Added
CC||jacobhemstad at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #14 from Michal Zientkiewicz ---
https://eel.is/c++draft/basic.start.term#3
If the completion of the constructor or dynamic initialization of an object
with static storage duration strongly happens before that of another, the
complet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #12 from Michal Zientkiewicz ---
As a side note - Clang emits the call to atexit between acquire and release and
the last demo works fine when compiled with Clang, but not GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #11 from Michal Zientkiewicz ---
Created attachment 50396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50396&action=edit
Demo with dependent variables
I added a new demo which shows that dependent variable gets destroyed afte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #10 from Jakub Jelinek ---
Even the swapping of the two calls would be IMHO a significant slowdown.
Because __cxa_atexit under the hood holds a global lock (fortunately not across
the duration of the whole user ctor, but across the in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #9 from Michal Zientkiewicz ---
(My previous comment may seem unclear, so let me clarify):
The _demo_ is not very useful, but the example in the example from the previous
comment is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #8 from Michal Zientkiewicz ---
Jakub: You read coorectly, I was checking for global construction/destruction
order of many variables. I agree that a global lock is a heavy-handed solution
- and likely the only one that would always g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #7 from Jakub Jelinek ---
Swapping __cxa_guard_release with __cxa_atexit would "fix" the case where the
user program would in all threads access all the local variables in the same
order. So all threads first access f<0>(), then f<1>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Or do you mean it is possible that for two unrelated variables
> variable 1 with its guard variable 2 with its guard
> __cxa_guard_acquire succeeds
> ct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #5 from Jakub Jelinek ---
The variables can be constructed even exactly at the same time, or at least the
ctors can be started concurrently and end concurrently. I don't think you can
rely on a particular ordering of the destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #4 from Michal Zientkiewicz ---
The problem is that the order of destruction is incorrect if there's a race
condition.
Consider 2 threads initializing static variables S1 and S2:
Thread A Thread B
acquire
construct S1
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
23 matches
Mail list logo
