On 15 Oct 2026 12:50, jim x via Std-Discussion wrote:
> If yes, then I think we already explained why we can’t make data-
> races with volatile to be implementation-defined, because that would
> force the implementation to pick a behavior with quite negative
> consequences, and we don’t want that.
>
> I agree that the behavior of the program in my question should be
> intended to be undefined behavior. What I don't agree with is that the
> wording in the current standard is clear enough to help us infer that
> the program contains a data race, especially since the standard
> doesn't formally define the term "atomic" appearing in [intro.race] p17.
>
> I think the wording should be rephrased to embody the meaning that the
> operations at `#1` and `#2` are *non-atomic* regardless of how the
> implementations give the semantics; for example, these operations are
> deemed non-atomic even though the implementation specifies them as
> std::atomic_ref::load()/ store() for their semantics.

This would make an implementation that implements volatiles using atomic
operations non-conforming. Where's the benefit of doing that?

As was said multiple times, regardless of what the implementation does,
the standard does not consider operations on volatiles as atomic
operations. It doesn't need to say that every operation besides <atomic>
is not atomic because that's the default. There's no ambiguity in the
current wording.