https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Bug ID: 99613
Summary: Static variable destruction order race condition
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
--- 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 #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 #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 #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 #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
