]> git.ipfire.org Git - thirdparty/gcc.git/commit
libstdc++: constrain std::atomic's default constructor
authorGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Sat, 21 Sep 2024 08:36:20 +0000 (10:36 +0200)
committerGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Sat, 8 Mar 2025 18:47:15 +0000 (19:47 +0100)
commit613f8ddbe3d7da63d827e588bf0333813c184b8a
tree8d09717835f04d0e8977a7dccd2a50aca5f4fede
parentdff059294511b4f42a531d0a91bf185ee1bc7b0a
libstdc++: constrain std::atomic's default constructor

This commit implements the proposed resolution to LWG4169, which is
to constrain std::atomic<T>'s default constructor based on whether
T itself is default constructible.

At the moment, std::atomic<T>'s primary template in libstdc++ has a
defaulted default constructor. Value-initialization of the T member
(since C++20 / P0883R2) is done via a NSDMI (= T()).

GCC already considers the defaulted constructor constrained/deleted,
however this behavior is non-standard (see the discussion in PR116769):
the presence of a NSDMI should not make the constructor unavailable to
overload resolution/deleted ([class.default.ctor]/2.5 does not apply).
When using libstdc++ on Clang, this causes build issues as the
constructor is *not* deleted there -- the interpretation of
[class.default.ctor]/4 seems to match Clang's behavior.

Therefore, although there would be "nothing to do" with GCC+libstdc++,
this commit changes the code as to stop relying on the GCC language
extension. In C++ >= 20 modes, std::atomic's defaulted default
constructor is changed to be a non-defaulted one, with a constraint
added as per LWG4169; value-initialization of the data member is moved
from the NSDMI to the member init list. The new signature matches the
one in the Standard as per [atomics.types.operations]/1.

In pre-C++20 modes, the constructor is left defaulted. This ensures
compatibility with C++11/14/17 behavior. In other words: we are not
backporting P0883R2 to earlier language modes here.

Amend an existing test to check that a std::atomic wrapping a
non-default constructible type is always non-default constructible:
from C++20, because of the constraint; before C++20, because we
are removing the NSDMI, and therefore [class.default.ctor]/2.5
applies.

Add another test that checks that std::atomic is trivially default
constructible in pre-C++20 modes, and it isn't afterwards.

libstdc++-v3/ChangeLog:

* include/bits/version.def (atomic_value_initialization):
Guard the FTM with the language concepts FTM.
* include/bits/version.h: Regenerate.
* include/std/atomic (atomic): When atomic value init is
defined, change the defaulted default constructor to
a non-defaulted one, constraining it as per LWG4169.
Otherwise, keep the existing constructor.
Remove the NSDMI for the _M_i member.
(_GLIBCXX20_INIT): Drop the macro, as it is not needed any more.
* testsuite/29_atomics/atomic/69301.cc: Test that
an atomic wrapping a non-default-constructible type is
always itself non-default-constructible (in all language
modes).
* testsuite/29_atomics/atomic/cons/trivial.cc: New test.
libstdc++-v3/include/bits/version.def
libstdc++-v3/include/bits/version.h
libstdc++-v3/include/std/atomic
libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/trivial.cc [new file with mode: 0644]