Issue 4069: std::atomic should be ill-formed (original) (raw)
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.
4069. std::atomic<volatile T> should be ill-formed
Section: 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, theatomic_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 issues3508(i) and 4069(i).
[2025-02-07 Status changed: Open → Resolved.]
Resolved by P3323R0 in Wrocław.
Proposed resolution: