Proposed resolution:

This wording is relative to N4849.

1. Modify [atomics.ref.ops] as indicated:

   static constexpr size_t required_alignment;
   

   -1- Let A be tThe alignment required for an object to be referenced by an atomic reference, which is at least alignof(T)so that is_always_lock_free is true. If there is no such alignment or A is less than alignof(T), required_alignment equals alignof(T). Otherwise, required_alignment equals A.

   -2- [Note: Hardware could require an object referenced by an atomic_ref to have stricter alignment ([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]

[ 2020-04-04 Issue Prioritization ]

Priority to 3 after reflector discussion.

N4849 [atomics.ref.ops]/1 describes atomic_ref<T>::required_alignment constant as follows:

The alignment required for an object to be referenced by an atomic reference, which is at least alignof(T).

This wording allows for an implementation to always define required_alignment to be equal to alignof(T) and implement atomic operations using locking, even if a lock-free implementation is possible at a higher alignment. For example, on x86-64, atomic_ref<complex<double>> could be lock-free only when the referred object is aligned to 16 bytes, but the above definition allows an implementation to define required_alignment to 8 and use locking.

The note in [atomics.ref.ops]/2 does mention that lock-free operations may require higher alignment, but it does not provide guidance to the implementations so that required_alignment reflects alignment required for lock-free operations, if possible, and not just minimum alignment required for any kind of implementation.

The suggested resolution is to change the wording so that it is clear that required_alignment indicates the alignment required for lock-free implementation, if one is possible, or alignof(T) otherwise.

Further, the note in [atomics.ref.ops]/2 contains this sentence:

Further, whether operations on an atomic_ref are lock-free could depend on the alignment of the referenced object.

This sentence is misleading, because according to is_lock_free() definition in [atomics.ref.ops]/4, the lock-free property is not allowed to depend on the alignment of a particular referenced object (is_lock_free() must return true or false if operations on all objects of the given type T are lock-free or not). In other words, atomic_ref can only refer to an object aligned at least to required_alignment and its lock-free capability cannot depend on the actual runtime alignment of the object.

To avoid the confusion, I propose to remove the sentence. The rest of the note can stay intact. However, this second edit is less important than the first one and can be omitted in case of disagreement.