On Wednesday, 14 October 2026 22:15:52 Pacific Daylight Time jim x wrote:
> But my question isn't about implementation conformance; that is, I didn't
> ask whether a conforming implementation can specify a concrete behavior for
> the undefined behavior program; of course, it can. I'm asking what the
> program's behavior should be, given the current wording, within the scope
> the standard leaves to implementations to define the semantics of access.

The problem here is what you're assuming can be implementation-defined. There
are a few things the Standard requires implementations make a choice,
document, and stick to it, which we call "implementation-defined behaviour". IB
is never UB. I don't think that there's anywhere that an IB choice can make
what is otherwise UB not so.

And then there's UB, which an implementation can, if it wants to, make defined.
It does not need to document it, but it can too. But making such choices does
not change the Standard. From its point of view, it's still UB.

> In other words, since the premise based on which we say the program is
> undefined is that the program contains a data race as per [intro.race] p17,
> which depends on whether the condition "at least one of which is not
> atomic" is true, the current wording is unclear about whether the
> operations at `#1` and `#2` are non-atomic even if the implementations
> define the semantics as being equivalent to
> `std::atomic_ref::load()/store()`.

There is a data race from the Standard's point of view.

If this implementation chose to implement the particular access in question
atomically, then in this implementation there would be no data race. But it
does not change the Standard: it's still UB from its point of view.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.