Let's say that the text was changed to say that it had an implementation defined behavior. Well then there would be almost no conformant compiler because none define a behavior and nobody would want too anyway.
It's intentionally left undefined so that the compiler implementation is allowed to ignore this condition and optimize code.

________________________________
From: Std-Discussion <std-discussion-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Discussion <std-discussion_at_[hidden]>
Sent: Tuesday, 13 October 2026 16:52:15
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>; jim x <xmh970252187_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?

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.