This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.
std::atomic<volatile T> should be ill-formedSection: 32.5.8 [atomics.types.generic] Status: Open Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2024-06-28
Priority: 2
View all other issues in [atomics.types.generic].
View all issues with Open status.
Discussion:
As a result of Core DR 2094
(concerning triviality of volatile-qualified subobjects),
is_trivially_copyable_v<volatile int> is now true,
which means that volatile int is a valid type for std::atomic.
Libstdc++ and libc++ can't actually compile that type though, and that seems very sensible to me.
Even worse is that std::atomic<volatile int> will not
select the specialization for int, because that is clearly specified by
32.5.8.3 [atomics.types.int] to only be for cv-unqualified types.
32.5.8.4 [atomics.types.float] also says it's only for cv-unqualified
floating-point types. And 32.5.8.5 [atomics.types.pointer] will only
match cv-unqualified pointer types.
This means that even when std::atomic<volatile int>
compiles (as with MSVC) you can't use members like fetch_add because that
only exists on the specialization, not the primary template.
Should we add something to std::atomic to make it not valid again,
as was the case (and presumably the original intent) before CWG DR 2094?
A similar question exists for std::atomic_ref<volatile int>
although there are apparently valid uses for that type. However, the
atomic_ref specializations for integers, floats, and pointers are only
for cv-unqualified types, so it doesn't work usefully.
For atomic_ref we might want to allow volatile-qualified types and
make the specializations match them.
[2024-04-29; Reflector poll]
Set priority to 2 after reflector poll and send to SG1.
[2024-06; Related to issue 3508(i).]
[St. Louis 2024-06-28; SG1 feedback]
SG1 forwarded P3323R0 to LEWG to resolve LWG issues 3508(i) and 4069(i).
Proposed resolution: