public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "michalz at nvidia dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99613] Static variable destruction order race condition Date: Tue, 16 Mar 2021 14:05:39 +0000 [thread overview] Message-ID: <bug-99613-4-36ROZSlLuE@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99613-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613 --- Comment #14 from Michal Zientkiewicz <michalz at nvidia dot com> --- 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 completion of the destructor of the second is sequenced before the initiation of the destructor of the first. If the completion of the constructor or dynamic initialization of an object with thread storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first. If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized. For an object of array or class type, all subobjects of that object are destroyed before any block variable with static storage duration initialized during the construction of the subobjects is destroyed. If the destruction of an object with static or thread storage duration exits via an exception, the function std::terminate is called ([except.terminate]). I think that makes at least the dependent variable case a requirement.
next prev parent reply other threads:[~2021-03-16 14:05 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-16 10:58 [Bug c++/99613] New: " michalz at nvidia dot com 2021-03-16 11:42 ` [Bug c++/99613] " rguenth at gcc dot gnu.org 2021-03-16 12:23 ` jakub at gcc dot gnu.org 2021-03-16 12:35 ` jakub at gcc dot gnu.org 2021-03-16 12:37 ` michalz at nvidia dot com 2021-03-16 12:42 ` jakub at gcc dot gnu.org 2021-03-16 12:48 ` rguenth at gcc dot gnu.org 2021-03-16 12:56 ` jakub at gcc dot gnu.org 2021-03-16 13:04 ` michalz at nvidia dot com 2021-03-16 13:07 ` michalz at nvidia dot com 2021-03-16 13:15 ` jakub at gcc dot gnu.org 2021-03-16 13:24 ` michalz at nvidia dot com 2021-03-16 13:25 ` michalz at nvidia dot com 2021-03-16 13:35 ` jakub at gcc dot gnu.org 2021-03-16 14:05 ` michalz at nvidia dot com [this message] 2021-03-16 14:07 ` jacobhemstad at gmail dot com 2021-03-16 14:23 ` jakub at gcc dot gnu.org 2021-03-16 14:38 ` rguenth at gcc dot gnu.org 2021-03-16 20:18 ` cvs-commit at gcc dot gnu.org 2021-03-19 23:30 ` cvs-commit at gcc dot gnu.org 2021-04-20 23:33 ` cvs-commit at gcc dot gnu.org 2021-04-22 16:51 ` cvs-commit at gcc dot gnu.org 2021-04-22 17:10 ` jakub at gcc dot gnu.org 2021-09-11 14:22 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99613-4-36ROZSlLuE@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).