[{"id":3680737,"web_url":"http://patchwork.ozlabs.org/comment/3680737/","msgid":"","list_archive_url":null,"date":"2025-03-08T00:05:41","subject":"Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's default\n constructor","submitter":{"id":93222,"url":"http://patchwork.ozlabs.org/api/people/93222/","name":"peppe via Sourceware Forge","email":"forge-bot+peppe@forge-stage.sourceware.org"},"content":"> I was undecided, but I think yes, please do. The change to constrain the ctor is a DR, not part of the published C++20 standard. Even though we already kinda emulated those semantics (non-portably) by using the NSDMI, you are now applying the resolution of the DR, so it would be good to indicate that with the comment.\n\nFair enough, applied the comment on the last version!\n\n--\nhttps://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-734","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org; dmarc=none (p=none dis=none)\n header.from=forge-stage.sourceware.org","sourceware.org;\n spf=pass smtp.mailfrom=forge-stage.sourceware.org","server2.sourceware.org;\n arc=none smtp.remote-ip=38.145.34.39"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g16G76lwXz1y2d\n\tfor ; Thu, 23 Apr 2026 03:50:55 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id EBC574BB58F9\n\tfor ; Wed, 22 Apr 2026 17:50:53 +0000 (GMT)","from forge-stage.sourceware.org (vm08.sourceware.org [38.145.34.39])\n by sourceware.org (Postfix) with ESMTPS id A07034BB58B4\n for ; Wed, 22 Apr 2026 17:48:26 +0000 (GMT)","from forge-stage.sourceware.org (localhost [IPv6:::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256)\n (No client certificate requested)\n by forge-stage.sourceware.org (Postfix) with ESMTPS id 530E942BF9\n for ; Wed, 22 Apr 2026 17:48:23 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org EBC574BB58F9","OpenDKIM Filter v2.11.0 sourceware.org A07034BB58B4"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A07034BB58B4","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A07034BB58B4","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776880106; cv=none;\n b=GOboo6MSUjNnx4sPG1kZlxKDncyWIvrh43L+6sGQQIFkB8kE4nJbclAMoyWzoeWQpHkAo0SMyZrzlSoy8oi/U+VI0IqWzuaaXEz0rEP5PAZ/xjYKAlhU0JXd2UDO1MWBVgdbcMmQsv2N+49l6RGWqUD+Ud07LlOXAIFchxmQfwM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776880106; c=relaxed/simple;\n bh=cjaFbbXxowRsViyKvwsFEHjqWlSGoJ1w1lKRRWqe+ZU=;\n h=Subject:From:To:Date:Message-ID:MIME-Version;\n b=l+4JGgpnujrExD9gRD9LxpQ+NSGjXEmdRyf5J3l/vzZX45o710EPpJgfILZ141sgqUQshGTX0ywMDj+TnijcocPg7+/mDuZ3EF0LTwbc7SqBptdLjNMFOs7L5d2D0dXiHd5Tg45hEPcN0oo7BqnC60Elzp9eRX+m4bjaR83sZsk=","ARC-Authentication-Results":"i=1; server2.sourceware.org","Subject":"Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's default\n constructor","From":"peppe via Sourceware Forge ","To":"gcc-patches mailing list ","Date":"Sat, 08 Mar 2025 00:05:41 +0000","Message-ID":"\n ","In-Reply-To":"\n ","X-Mailer":"batrachomyomachia","X-Requested-Reviewer":"redi","X-Pull-Request-Organization":"gcc","X-Pull-Request-Repository":"gcc-TEST","X-Pull-Request":"https://forge.sourceware.org/gcc/gcc-TEST/pulls/36","X-Comment":"https://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-734","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3680739,"web_url":"http://patchwork.ozlabs.org/comment/3680739/","msgid":"","list_archive_url":null,"date":"2026-04-22T17:48:26","subject":"[SUMMARY] Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's\n default constructor","submitter":{"id":93222,"url":"http://patchwork.ozlabs.org/api/people/93222/","name":"peppe via Sourceware Forge","email":"forge-bot+peppe@forge-stage.sourceware.org"},"content":"This is a summary of discussions relative to the merge request created by (peppe) titled\nWIP: libstdc++: constrain std::atomic's default constructor\nsince its creation.\n\nDescription: This commit implements the proposed resolution to LWG4169, which is\nto constrain std::atomic's default constructor based on whether\nT itself is default constructible.\n\nAt the moment, std::atomic's primary template in libstdc++ has a\ndefaulted default constructor. Value-initialization of the T member\n(since C++20 / P0883R2) is done via a NSDMI (= T()).\n\nGCC already considers the defaulted constructor constrained/deleted,\nhowever this behavior is non-standard (see the discussion in PR116769):\nthe presence of a NSDMI should not make the constructor unavailable to\noverload resolution/deleted ([class.default.ctor]/2.5 does not apply).\nWhen using libstdc++ on Clang, this causes build issues as the\nconstructor is *not* deleted there -- the interpretation of\n[class.default.ctor]/4 seems to match Clang's behavior.\n\nTherefore, although there would be \"nothing to do\" with GCC+libstdc++,\nthis commit changes the code as to stop relying on the GCC language\nextension. std::atomic's defaulted default constructor is changed to be\na non-defaulted one, with a constraint added as per LWG4169;\nvalue-initialization of the data member is moved from the NSDMI to the\nmember init list. The new signature matches the one in the Standard as\nper [atomics.types.operations]/1.\n\nA test that explictly instantiated std::atomic with a non-default\nconstructible type needed to be amended. Such an instantiation would\ninstantiate all member functions (as per [temp.explicit]/9), including\nthe default constructor, which now triggers a hard error when built in\npre-C++20 modes.\n\nIn its place I've instead added a couple of static_asserts checking that\nstd::atomic is default constructible even with a non-default\nconstructible T (in pre-C++20 modes), or is not default constructible\nat all (since C++20).\n\n```\nlibstdc++-v3/ChangeLog:\n\n\t* include/std/atomic (atomic): Turn the defaulted default\n\tconstructor in a non-defaulted one, constraining it as per\n\tLWG4169; remove the NSDMI for the _M_i member.\n\t(_GLIBCXX20_INIT): Drop the macro, as it is not needed any more.\n\t* testsuite/29_atomics/atomic/69301.cc: Restrict the explicit\n\tclass instantation only to C++ >= 20 modes; it would otherwise\n\tcause a hard error. Add a new test.\n\t* testsuite/29_atomics/atomic/cons/value_init.cc: Add a new test.\n```\n\nThe full and up to date discussion can be found at https://forge.sourceware.org/gcc/gcc-TEST/pulls/36\n\nThe merge request has been closed without being merged directly on the forge repository.\n\nOn 2025-03-06 10:33:34+00:00, (peppe) requested that Jonathan Wakely (redi) review the code:\n\n\n\n\nOn 2025-03-06 13:26:18+00:00, (tkaminsk) commented on the code:\n\n\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\nThis seem to change the behavior when the `__cpp_lib_atomic_value_initialization` is not defined. \nWithout the NDMIS on `_M_i` the defaulted constructor would be trivial for trivially default constructible types (basically nearly everything that is put in atomic), now the destruct is user provided.\n\nWe also unconditionally check `is_nothrow_default_constructible` that may lead to program being ill-formed (hard-error) if instantiation of default argument causes instantation of template that is ill-formed, for example:\n```\n#include \n\ntemplate \nstruct DA {\n static_assert(!std::is_same_v);\n constexpr static T value{};\n};\n\ntemplate\nstruct S {\n template\n S(U t = DA::value);\n};\n\nbool b = std::is_nothrow_default_constructible_v>;\n```\n(See https://godbolt.org/z/31jr1Eoed). Also it is not clear if default arguments are part of immediate context in standard.\n\nI think you should switch between defaulting on first declaration or new definition.\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\n@tkaminsk wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-687:\n\n> This seem to change the behavior when the `__cpp_lib_atomic_value_initialization` is not defined. Without the NDMIS on `_M_i` the defaulted constructor would be trivial for trivially default constructible types (basically nearly everything that is put in atomic), now the destruct is user provided.\n\nThat's a very good point. I think there's something to decide here, which is whether we consider P0883 a C++20-only change, or a defect fix to be applied to all C++ modes (because it resolves https://cplusplus.github.io/LWG/issue2334 ). I've reported implementation divergence in this SG1 thread on this issue: \n\nhttps://lists.isocpp.org/parallel/2024/10/4401.php\n\nbut it was inconclusive...\n\n\n> I think you should switch between defaulting on first declaration or new definition.\n\nDo you mean something like this?\n\n```\n#if __cpp_lib_atomic_value_initialization\nconstexpr atomic() noexcept(...) requires(...) : _M_i() {}\n#else\natomic() = default;\n#endif\n```\n\n\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\nYes, I like that suggestion. It makes the change a complete no-op for C++11/14/17\n\nMy remaining concern would be whether we can use a _requires-clause_ for older versions of Clang. I think Clang 17 has good enough support for concepts so this will work.\n\nArguably, we could make this change now instead of waiting for stage 1, because we're not changing anything for C++17 mode. I think I'd still prefer to wait for GCC 16, and then if it causes no problems we can backport it to GCC 15.2 too.\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\n> That's a very good point. I think there's something to decide here, which is whether we consider P0883 a C++20-only change, or a defect fix to be applied to all C++ modes (because it resolves https://cplusplus.github.io/LWG/issue2334 ). I've reported implementation divergence in this SG1 thread on this issue:\n> \n> https://lists.isocpp.org/parallel/2024/10/4401.php\n> \n> but it was inconclusive...\n\nAs your implementation uses requires clause we have implicit dependency on concepts feature which requires c++20. As currently we apply this change only for C++20 or later, I think we should keep it that way, instead of complicating the code.\n\nI have removed the suggestion on adding `extra_cond` to feature test macro file, see my later response.\n\n> \n> > I think you should switch between defaulting on first declaration or new definition.\n> \n> Do you mean something like this?\n> \n> ```text\n> #if __cpp_lib_atomic_value_initialization\n> constexpr atomic() noexcept(...) requires(...) : _M_i() {}\n> #else\n> atomic() = default;\n> #endif\n> ```\n\nYes, something like that.\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\n@redi wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/36/files#issuecomment-691:\n\n> My remaining concern would be whether we can use a _requires-clause_ for older versions of Clang. I think Clang 17 has good enough support for concepts so this will work.\n> \n\nclang-14 seem to have sufficient concept support to handle this case: https://godbolt.org/z/fTofYsqEd.\nHowever, it does not define `__cpp_concepts` to value ` 202002L` to indicate that, so my idea of adding an `extra_cond` will works against the goal of this patch.\n\n\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\nWe don't need to care about clang 14 now. Users of clang 14 should either upgrade, or stick to C++17, or live without std::atomic value initialization.\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\nDoes that really require `__cpp_concepts >= 202002L`? I think [P0848](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0848r3.html) allows you to overload a special member, using constraints so one is trivial and one is non-trivial.\n\nWe don't need that here, we only want one default constructor, with a constraint. If the constraint isn't satisfied, the default constructor isn't usable. I think the original concepts design (i.e. `__cpp_concepts >= 201907L`) is good enough for that. Which is why old versions of Clang support it.\n> +++ libstdc++-v3/include/std/atomic\n> @@ -233,3 +226,3 @@\n> \n> public:\n> - atomic() = default;\n> + constexpr atomic() noexcept(is_nothrow_default_constructible<_Tp>::value)\n@redi wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-703:\n\n> Does that really require `__cpp_concepts >= 202002L`? I think [P0848](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0848r3.html) allows you to overload a special member, using constraints so one is trivial and one is non-trivial.\n\nYou are right, we are not overloading the destructor, so it's same as any other constrains on member function.\n\n> We don't need that here, we only want one default constructor, with a constraint. If the constraint isn't satisfied, the default constructor isn't usable. I think the original concepts design (i.e. `__cpp_concepts >= 201907L`) is good enough for that. Which is why old versions of Clang support it.\n\nMake sense. @peppe Could you also adjust the `bits/version.def` definition of `atomic_value_initialization` so it have `extra_cond = \"__cpp_concepts >= 201907L\"`. These will document that current implementation depends on concepts and if we would like to apply it to eariel standard we need to update implementiation. These should look something like:\n```\nftms = {\n name = atomic_value_initialization;\n values = {\n v = 201911;\n cxxmin = 20;\n extra_cond = \"__cpp_concepts >= 201907L\";\n };\n};\n\n```\n\n\nOn 2025-03-07 09:28:05+00:00, (peppe) wrote:\n\nA code style question: in lots of places I've spotted comments with _GLIBCXX_RESOLVE_LIB_DEFECTS, should I add one here too (just before the constructor) mentioning 4169? Or that meta-comment is for when libstdc++ resolves defects _before_ LWG says they're defects?\n\n\nOn 2025-03-07 15:51:55+00:00, Jonathan Wakely (redi) wrote:\n\n> in lots of places I've spotted comments with _GLIBCXX_RESOLVE_LIB_DEFECTS,\n\nWe use that comment to record when a DR has been applied to the source. It's a lot easier to see a comment that says LWG 4169 was fixed, than to examine the code and try to figure out if we have done it yet or not.\n\nThere's no formal policy, but I don't bother using it when it's an LWG issue fixing something in an unpublished standard, so e.g. issues in new C++26 components don't really need that marker, since the issue resolution will be part of the final C++26 standard when it's published, and that's what we should be implementing. But for a DR against a published standard, it's useful as an indicator that (1) we have implemented the resolution and (2) the code deviates from the published standard because of a DR, not just by accident or a bug.\n\n> should I add one here too (just before the constructor) mentioning 4169? \n\nI was undecided, but I think yes, please do. The change to constrain the ctor is a DR, not part of the published C++20 standard. Even though we already kinda emulated those semantics (non-portably) by using the NSDMI, you are now applying the resolution of the DR, so it would be good to indicate that with the comment.\n\n> Or that meta-comment is for when libstdc++ resolves defects before LWG says they're defects?\n\nNo, it is sometimes used that way if we proactively apply a resolution that we think is correct, but it's also used when we resolve something that has already been approved by LWG polls and/or WG21 plenary polls.\n\nWe do also have https://gcc.gnu.org/onlinedocs/libstdc++/manual/bugs.html which lists supported DRs, but it's not complete, and nobody except me bothers to update it :joy: I used to try to update that when we implemented a DR that made a significant, observable change that could impact users. I should probably update it some time. (This fix doesn't need to be there, since this change isn't likely to change the behaviour of much valid code, especially not for GCC users who had the non-standard NSDMI effects already).\n\n\n\n\nOn 2025-03-08 00:05:41+00:00, (peppe) wrote:\n\n> I was undecided, but I think yes, please do. The change to constrain the ctor is a DR, not part of the published C++20 standard. Even though we already kinda emulated those semantics (non-portably) by using the NSDMI, you are now applying the resolution of the DR, so it would be good to indicate that with the comment.\n\nFair enough, applied the comment on the last version!\n\nOn 2025-03-08 10:26:31+00:00, Jonathan Wakely (redi) commented on the code:\n\n\n> +++ libstdc++-v3/include/std/atomic\n> @@ -51,6 +51,7 @@\n> \n> #include \n> #include \n> +#include \nIt's usually not necessary to include `` if *any* other header (except the `` C headers) has been included. Everything includes ``, or `` which includes ``, so it was already guaranteed to be brought in by ``. It doesn't hurt to leave it though, the compiler won't reopen it if it's been seen already so the cost is minimal.\n> +++ libstdc++-v3/testsuite/29_atomics/atomic/69301.cc\n> @@ -31,1 +31,4 @@\n> \n> +// On GCC this holds even in pre-C++20 / without LWG4169 because of a\n> +// language extension; see PR116769 (the defaulted default constructor\n> +// is \"implicitly\" constrained).\nIs this comment still relevant with the current version of the changes in ``?\n\nThe GCC language extension only applies when a NSDMI is present, right? And there's no NSDMI pre-C++20 (nor post-C++20).\n\nSo this `static_assert` should pass for all compilers. Pre-C++20 the default ctor is implicitly defined as deleted, and since C++20 it's constrained.\n> +++ libstdc++-v3/testsuite/29_atomics/atomic/69301.cc\n> @@ -31,1 +31,4 @@\n> \n> +// On GCC this holds even in pre-C++20 / without LWG4169 because of a\n> +// language extension; see PR116769 (the defaulted default constructor\n> +// is \"implicitly\" constrained).\nGood point. I've got rid of these comments, and amended the commit message. Hope it's clear now,\n* from C++20 we have the constraint\n* before C++20, by removing the NSDMI, the default constructor is deleted because of https://eel.is/c++draft/class.default.ctor#2.5\n\n\nOn 2025-03-08 17:07:58+00:00, Jonathan Wakely (redi) wrote:\n\nOK for trunk, please push and send the final version of the patch to the mailing list for the archives - thanks!\n\n\nOn 2025-03-08 19:06:26+00:00, (peppe) wrote:\n\n@redi wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-741:\n\n> OK for trunk, please push and send the final version of the patch to the mailing list for the archives - thanks!\n\nThank you! All done. I'll close this PR.\n\n\nOn 2026-04-22 17:47:58+00:00, Lichenor Forgejo Bot (forge-bot) wrote:\n\n\nVersion 1 of this pull request has been stored. It includes the following commits:\n- libstdc++: constrain std::atomic's default constructor - 50befa32f7cc696850607d9c09b81a4de529597a\n\n\n\nOn 2026-04-22 17:48:22+00:00, Lichenor Forgejo Bot (forge-bot) wrote:\n\nSent patch series version 1 containing 1 patches to gcc-patches mailing list .\n[Cover letter](https://inbox.sourceware.org/gcc-patches/bmm.hhunfc5mlg.gcc.gcc-TEST.peppe.36.1.0@forge-stage.sourceware.org)","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org; dmarc=none (p=none dis=none)\n header.from=forge-stage.sourceware.org","sourceware.org;\n spf=pass smtp.mailfrom=forge-stage.sourceware.org","server2.sourceware.org;\n arc=none smtp.remote-ip=38.145.34.39"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g16HZ17swz1y2d\n\tfor ; Thu, 23 Apr 2026 03:52:10 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 253094BB3BE7\n\tfor ; Wed, 22 Apr 2026 17:52:08 +0000 (GMT)","from forge-stage.sourceware.org (vm08.sourceware.org [38.145.34.39])\n by sourceware.org (Postfix) with ESMTPS id 2CEB84BB5885\n for ; Wed, 22 Apr 2026 17:48:27 +0000 (GMT)","from forge-stage.sourceware.org (localhost [IPv6:::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256)\n (No client certificate requested)\n by forge-stage.sourceware.org (Postfix) with ESMTPS id 3EB5C42BFF\n for ; Wed, 22 Apr 2026 17:48:26 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 253094BB3BE7","OpenDKIM Filter v2.11.0 sourceware.org 2CEB84BB5885"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 2CEB84BB5885","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 2CEB84BB5885","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776880107; cv=none;\n b=J2CGzda+rY+Cjin22jVNhgdR6o+WDoJ8TCeroSsCcS/O/kyJQcW24dPrBA2Aj0fMlGkPkzIrgBWM8EjSRXJXxWoeF6jkYk2ad0VOFm5QwfGmoe4YD5ZMzo4gLb4X1YSH9D92oK1sNg13+hHeH+xckUfHWGmatolmVSTFdyViigc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776880107; c=relaxed/simple;\n bh=4rNSVvYRu13jGoKOXBU3rFztbx68Bfv4UPw+hb61OY4=;\n h=Subject:From:To:Message-ID:MIME-Version:Date;\n b=JOs0exjIOIC3CeDr6wQR8zuFcVgX8vrM3r4KFQBUorrnd3061HAcBWbuk4uLviWWpsmOwLGg70M1qGSBFsaENDumvoJJkKr/gaQWZq16mKCbc28vhOw3/ChxYrzFdxb029ScfrzXNpMoxPWBPQytbB9Ok/ZB0GK8+LxQ2oqa+g8=","ARC-Authentication-Results":"i=1; server2.sourceware.org","Subject":"[SUMMARY] Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's\n default constructor","From":"peppe via Sourceware Forge ","To":"gcc-patches mailing list ","In-Reply-To":"\n ","Message-ID":"\n ","X-Mailer":"batrachomyomachia","X-Requested-Reviewer":"redi","X-Pull-Request-Organization":"gcc","X-Pull-Request-Repository":"gcc-TEST","X-Pull-Request":"https://forge.sourceware.org/gcc/gcc-TEST/pulls/36","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","Date":"Wed, 22 Apr 2026 17:48:26 +0000 (UTC)","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3680740,"web_url":"http://patchwork.ozlabs.org/comment/3680740/","msgid":"","list_archive_url":null,"date":"2025-03-08T10:33:23","subject":"Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's default\n constructor","submitter":{"id":93210,"url":"http://patchwork.ozlabs.org/api/people/93210/","name":"Jonathan Wakely via Sourceware Forge","email":"forge-bot+redi@forge-stage.sourceware.org"},"content":"Jonathan Wakely (redi) ) commented on the code:\n\n\n> +++ libstdc++-v3/include/std/atomic\n> @@ -51,6 +51,7 @@\n> \n> #include \n> #include \n> +#include \nIt's usually not necessary to include `` if *any* other header (except the `` C headers) has been included. Everything includes ``, or `` which includes ``, so it was already guaranteed to be brought in by ``. It doesn't hurt to leave it though, the compiler won't reopen it if it's been seen already so the cost is minimal.\n\n> +++ libstdc++-v3/testsuite/29_atomics/atomic/69301.cc\n> @@ -31,1 +31,4 @@\n> \n> +// On GCC this holds even in pre-C++20 / without LWG4169 because of a\n> +// language extension; see PR116769 (the defaulted default constructor\n> +// is \"implicitly\" constrained).\nIs this comment still relevant with the current version of the changes in ``?\n\nThe GCC language extension only applies when a NSDMI is present, right? And there's no NSDMI pre-C++20 (nor post-C++20).\n\nSo this `static_assert` should pass for all compilers. Pre-C++20 the default ctor is implicitly defined as deleted, and since C++20 it's constrained.\n\n> +++ libstdc++-v3/testsuite/29_atomics/atomic/69301.cc\n> @@ -31,1 +31,4 @@\n> \n> +// On GCC this holds even in pre-C++20 / without LWG4169 because of a\n> +// language extension; see PR116769 (the defaulted default constructor\n> +// is \"implicitly\" constrained).\nGood point. I've got rid of these comments, and amended the commit message. Hope it's clear now,\n* from C++20 we have the constraint\n* before C++20, by removing the NSDMI, the default constructor is deleted because of https://eel.is/c++draft/class.default.ctor#2.5\n\n\n--\nhttps://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-737","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org; dmarc=none (p=none dis=none)\n header.from=forge-stage.sourceware.org","sourceware.org;\n spf=pass smtp.mailfrom=forge-stage.sourceware.org","server2.sourceware.org;\n arc=none smtp.remote-ip=38.145.34.39"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g16Hc3gkzz1y2d\n\tfor ; Thu, 23 Apr 2026 03:52:12 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 82C634BB58D6\n\tfor ; Wed, 22 Apr 2026 17:52:10 +0000 (GMT)","from forge-stage.sourceware.org (vm08.sourceware.org [38.145.34.39])\n by sourceware.org (Postfix) with ESMTPS id A61F74BB58B6\n for ; Wed, 22 Apr 2026 17:48:26 +0000 (GMT)","from forge-stage.sourceware.org (localhost [IPv6:::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256)\n (No client certificate requested)\n by forge-stage.sourceware.org (Postfix) with ESMTPS id 671E742BFA\n for ; Wed, 22 Apr 2026 17:48:23 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 82C634BB58D6","OpenDKIM Filter v2.11.0 sourceware.org A61F74BB58B6"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A61F74BB58B6","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A61F74BB58B6","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776880106; cv=none;\n b=o2XajdE3iCFZZnbSZnmG0zuRuYqfK6Ojr7AhjA66Xh8pK6vsEOv/Zap5tXQhjgcbhGPOz9zm1Sr9B/YVZtaFtOWFOd/uwJwvOqZc9LkQVf5QoIXQdv7vb/ui0cGvRG5iJT5vV2ilMu/Vk/KEyknpz1ha/zV9Qds8CN3PZ3vaxTw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776880106; c=relaxed/simple;\n bh=LJebNGqYl+hySn4CejxJuj4cVHVLGHPJv0+NYgd/tJQ=;\n h=Subject:From:To:Date:Message-ID:MIME-Version;\n b=csAfFcHnPetHnLnNdvGOu2acB2/Tdi2wbtzPLVj13QrYuFazU0Wod6QxesaDpnMFribJ3ho8BKqlvQATjbK24Fk0wDZT+BsZmpbGB4VUncK7bcqLFEQSOzaJ3ZrUh2tIOLbBsSQ6gQtBFsqum6PjcX1SDusbaoDRpwTI325eQ10=","ARC-Authentication-Results":"i=1; server2.sourceware.org","Subject":"Re: [PATCH v1 0/1] WIP: libstdc++: constrain std::atomic's default\n constructor","From":"Jonathan Wakely via Sourceware Forge\n ","To":"gcc-patches mailing list ","Date":"Sat, 08 Mar 2025 10:33:23 +0000","Message-ID":"\n ","In-Reply-To":"\n ","X-Mailer":"batrachomyomachia","X-Requested-Reviewer":"redi","X-Pull-Request-Organization":"gcc","X-Pull-Request-Repository":"gcc-TEST","X-Pull-Request":"https://forge.sourceware.org/gcc/gcc-TEST/pulls/36","X-Review":"https://forge.sourceware.org/gcc/gcc-TEST/pulls/36#issuecomment-737","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]