std::atomic<volatile T> should be ill-formed
Jonathan Wakely

Created on 2024-04-19.00:00:00 last changed 5 days ago


Date: 2024-06-10.09:25:40

[ 2024-06; Related to issue 3508. ]

Date: 2024-04-15.00:00:00

[ 2024-04-29; Reflector poll ]

Set priority to 2 after reflector poll and send to SG1.

Date: 2024-04-22.09:06:59

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 [atomics.types.int] to only be for cv-unqualified types. [atomics.types.float] also says it's only for cv-unqualified floating-point types. And [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.

Date User Action Args
2024-06-10 09:25:40adminsetmessages: + msg14163
2024-04-29 20:24:43adminsetmessages: + msg14088
2024-04-29 20:24:43adminsetstatus: new -> open
2024-04-19 00:00:00admincreate