Compilers were always free to do more than what the standard prescribes.
The standard is not a description of what compilers actually do, but an idealized concept.
If the standard does not prescribe something then it doesn't not prescribe it, you can do something extra but that doesn't change what is prescribed.

________________________________
From: Std-Discussion <std-discussion-bounces_at_[hidden]> on behalf of Andrey Semashev via Std-Discussion <std-discussion_at_[hidden]>
Sent: Tuesday, October 13, 2026 2:43:06 PM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?

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.

--
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion