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?

On Sun, Oct 11, 2026 at 4:24 AM Thiago Macieira via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Saturday, 10 October 2026 03:09:02 Eastern Daylight Time jim x via Std-
> Discussion wrote:
> > However, saying a program has undefined behaviour could imply the program
> > is *unconditionally* undefined behavior; I don't think this is true.
>
> It is true. The behaviour, *according to the Standard*, is undefined.
>
> But machines are deterministic. Once compiled, the program will have
> *some*
> behaviour. Data races and non-atomic accesses may have one of multiple
> deterministic behaviours, but which one cannot be determined ahead of time.
>
> That does not change the Standard. The fact that some implementation may
> define
> a specific undefined behaviour to be very specifically determined does not
> remove
> the fact that the Standard still said it was undefined.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>