On 13 Oct 2026 15:18, Giuseppe D'Angelo via Std-Discussion wrote:
> Il 13/10/26 12:24, Andrey Semashev via Std-Discussion ha scritto:
>> You got it backwards. If the standard doesn't say volatile operations
>> are atomic then they are not. Or put it another way, you cannot rely on
>> them being atomic. Atomicity is not implied, the standard must
>> explicitly require an operation to be atomic for an implementation to
>> make an effort in making them atomic in the compiled program.
>
> Devil's advocate here: can an implementation say that reading a
> `volatile int x` is defined as doing `atomic_ref<int>(x).load()`?
>
> (Same for the rest of operations.)

It can, and that would be an example of an implementation-defined behavior.

> If yes, would that make concurrent access to volatile ints not subject
> to data races?

On that particular implementation, yes. According to the standard or on
other implementations that do not use atomic operations for volatiles, no.