Doesn't such behavior depend on how the implementation defines its
semantics? That is, *shouldn't it be considered implementation-defined,
rather than unconditionally undefined?*

On Tue, Oct 13, 2026 at 8:43 PM Andrey Semashev via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> 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
>