I'm trying to express the ambiguity I think about the wording.

It doesn't say that accesses to volatiles *are* atomic.


Yes. However, the standard simultaneously permits the implementation to
define the semantics, which leaves a slot for implementations to define the
parameterized part of the abstract machine. This leaves room for us to
think about whether the operations associated with volatile glvalue
are atomic or non-atomic* because they are parameterized by the
implementations. *This is my confusion about the wording.

On Tue, Oct 13, 2026 at 10:52 PM Thiago Macieira <thiago_at_[hidden]>
wrote:

> On Tuesday, 13 October 2026 01:43:01 Pacific Daylight Time jim x wrote:
> > One of the grounds for your claim that the program exhibits undefined
> > behavior is that you determined it contains a data race based on
> > [intro.race] p17. But the very issue is: where does the standard state
> that
> > an access to a volatile glvalue is non-atomic? The standard does not even
> > define the semantics of such accesses and leaves them
> > implementation-defined, making it even less possible to assert that
> > accesses to a volatile glvalue are non-atomic. How, then, can you
> conclude
> > based on [intro.race] that this program contains a data race?
>
> It doesn't say that accesses to volatiles *are* atomic. Therefore, they
> aren't
> required to be and thus your example is a data race.
>
> jim, you've argued this over and over again. Everyone has the same
> interpretation of the Standard except you and you keep arguing the same
> thing
> over and over again. What do you want to happen? Do you want a Standard
> text
> change to clarify things one way or another? If so, please propose it. Are
> you
> trying to argue with a vendor about their functionality?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>