On 31 Mar 2026 18:51, Nate Eldredge wrote:
>
>> On Mar 31, 2026, at 01:55, Andrey Semashev via Std-Discussion <std-
>> discussion_at_[hidden]> wrote:
>>
>> Consider what is referred to as a "spurious failure", which is defined
>> in p27 (https://eel.is/c++draft/atomics.types.operations#27 <https://
>> eel.is/c++draft/atomics.types.operations#27>):
>>
>> Remarks: A weak compare-and-exchange operation may fail spuriously.
>> That is, even when the contents of memory referred to by expected and
>> this are equal, it may return false and store back to expected the
>> same memory contents that were originally there.
>>
>> So, the behavior in the case of a spurious failure would be equivalent
>> to that of when the comparison legitimately returns false.
>
> I certainly agree that's what's intended, but "equivalent" is not what
> p27 actually says. It says that on spurious failure, `false` is
> returned and `expected` is stored to. Those are only two of the three
> things that p23 says will happen when the comparison is false; the third
> is the ordering of memory according to `failure`, and that one's not
> mentioned by p27.

My reading of p27 is that a spurious failure has the same behavior as if
the values were actually not equal, and given p23 that also includes the
memory ordering semantics. But maybe there are some language formalities
that I'm glossing over.

> There is another (unrelated) issue raised by that passage. Suppose
> `expected` contains an object whose value representation agrees with
> `*this`, but whose padding bits differ; the comparison returns `true` in
> this case. Suppose the compare-exchange then fails spuriously. Is
> `expected` then modified to have the same padding bits that were in
> `*this`? The phrasing "same memory contents" is ambiguous as to whether
> it means "same object representation" or "same value representation".
> Indeed, "memory contents" is not formally defined or used anywhere else
> in the Standard.
>
> If anything, using the phrase "memory contents" instead of "value" makes
> it sound like the object representation is intended; i.e. the padding
> bits of `expected` should not be changed on spurious failure.

The way it is specified, a spurious failure results in a store to
`expected`, and the store is allowed to modify padding bits. IMO, this
should remain the case. Otherwise, you would be prohibiting the store to
`expected` and that would have performance implications, if at all
implementable (because the implementation now has to distinguish between
a spurious and legitimate failure, which may not be possible).

Note that the modification of the padding bits won't affect a potential
future compare_exchange since the comparison is required to disregard
padding bits.