This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4453. atomic_ref<cv T>::required_alignment should be the same as for T

Section: 32.5.7.2 [atomics.ref.ops] Status: New Submitter: Jonathan Wakely Opened: 2025-11-06 Last modified: 2026-02-27

Priority: 2

View other active issues in [atomics.ref.ops].

View all other issues in [atomics.ref.ops].

View all issues with New status.

Discussion:

When P3323R1 fixed support for atomic_ref<cv T> we didn't consider that an implementation could define required_alignment to be different from atomic_ref<T>::required_alignment. For example, a processor could support atomic loads on any int object, but could require a greater alignment for atomic stores (and read-modify-write and modify-write operations). So the required_alignment could be alignof(int) for const int but 2 * alignof(int) for int, because the latter is needed for stores.

A malicious implementation could even define required_alignment to be greater for the const T specialization, which would make it undefined to use the new converting constructor added by P3860R1.

We should constrain implementations to use the same required_alignment for cv T, so that users can use atomic_ref<const T> on any object that is referenced by a atomic_ref<T>.

[2026-01-16; Reflector poll.]

Set priority to 2 after reflector poll.

"Should be broaded to include all similar types, not just top-level cv."

"Should we have the same guarantee for is_always_lock_free? Would allow checking if atomic<volatile T> is usable by checking atomic<T>."

Previous resolution [SUPERSEDED]:

This wording is relative to N5014.

1. Modify [atomics.refs.ops], as indicated:

   static constexpr size_t required_alignment;
   

   -1- The alignment required for an object to be referenced by an atomic reference, which is at least alignof(T). The value of required_alignment is the same as atomic_ref<remove_cv_t<T>>::required_alignment

   -2- [Note 1: Hardware could require an object referenced by an atomic_ref to have stricter alignment (6.8.3 [basic.align]) than other objects of type T. Further, whether operations on an atomic_ref are lock-free could depend on the alignment of the referenced object. For example, lock-free operations on std::complex<double> could be supported only if aligned to 2*alignof(double). — end note]

[2026-02-16; Tomasz provides updated resolution.]

Guarantee that required_alignment and is_always_lock_free values are the same for any similar types.

We define equality to atomic_ref<remove_cv_t<U>, as volatile atomics may be ill-formed.

Proposed resolution:

This wording is relative to N5032.

1. Modify [atomics.refs.ops], as indicated:

   static constexpr size_t required_alignment;
   

   -1- The alignment required for an object to be referenced by an atomic reference, which is at least alignof(T). For any type U similar to T, the value of required_alignment is the same as atomic_ref<remove_cv_t<U>>::required_alignment.

   -2- [Note 1: Hardware could require an object referenced by an atomic_ref to have stricter alignment (6.8.3 [basic.align]) than other objects of type T. Further, whether operations on an atomic_ref are lock-free could depend on the alignment of the referenced object. For example, lock-free operations on std::complex<double> could be supported only if aligned to 2*alignof(double). — end note]

   static constexpr bool is_always_lock_free;
   

   -3- The static data member is_always_lock_free is true if the atomic_ref type's operations are always lock-free, and false otherwise. For any type U similar to T the value of is_always_lock_free is the same as atomic_ref<remove_cv_t<U>>::is_always_lock_free.