This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
std::atomic<volatile T> should be ill-formedSection: 32.5.8 [atomics.types.generic] Status: Resolved Submitter: Jonathan Wakely Opened: 2024-04-19 Last modified: 2025-02-07
Priority: 2
View all other issues in [atomics.types.generic].
View all issues with Resolved 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).
[2025-02-07 Status changed: Open → Resolved.]
Resolved by P3323R0 in Wrocław.
Proposed resolution: