From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 709E63858D33; Fri, 6 Jan 2023 19:57:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 709E63858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673035056; bh=dOJm0MPzBnd0fGGIvIim9YzfJe7PWmA19NvTFIeGoQU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RKqEDBSZSU0xLj4/Rl/o/G9MDwFRvW0wZyXWmVInhj2zEknHYoGMkj6gzvLHMsWlk f38wJA4CY8RGJkHvE/q9zcFHJ/CxoCezDAjRXGTweIkJvzKW1uc0rYlNM78Y6Yk1ms DOJjOeK/38jMKyue+wPJPTbb/6TDsKE+PJh+w0Tk= From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced Date: Fri, 06 Jan 2023 19:57:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jason at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on assigned_to keywords resolution bug_status everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108299 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-01-06 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gn= u.org Keywords| |wrong-code Resolution|INVALID |--- Status|RESOLVED |ASSIGNED Ever confirmed|0 |1 --- Comment #10 from Jason Merrill --- (In reply to Jakub Jelinek from comment #6) Hmm, I don't see the ABI problem: wrappers are comdat/weak and prepared to handle the absence of an init function, so TUs that either use or don't use wrappers should be ABI-compatible, though of course you would need both to = be recompiled to get the currently specified behavior. For performance, the one degradation I see is preventing the PR101786 optimization with extern constinit. https://github.com/cplusplus/CWG/issues/210=