On Thu, Oct 15, 2026, 1:15 AM jim x <xmh970252187@gmail.com> 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. 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()`.

The behavior of the program in the hypothetical implementation is clear, though. You are not asking any concrete question about the behavior. You're asking whether it falls into the category of "undefined behavior" or "implementation-defined behavior" and this is the flaw in your question. These terms come from the standard, so they have no meaning outside of specifying implementation compliance. Your insistence on the standard providing you with a categorization is frustrating. It feels like you're asking "have you stopped beating your wife yet, yes or no?" and repeatedly refusing to accept that the question is not answerable in that form.

In terms of the concrete behavior, I believe it's clear for the following reason. First, let me introduce new terms: "bounded" and "unbounded". An execution of a program on an implementation has "unbounded" behavior if the program can crash, launch missiles, or otherwise exhibit any behavior that is possible for an executable under the implementation's operating system and hardware. An execution of a program on an implementation is "bounded" if it is not unbounded. Now, if a hypothetical implementation documents that volatile accesses behave as if they are accesses through `atomic_ref`, what is the documentation trying to tell us? Is the behavior of your program bounded or unbounded? It is obviously bounded---the program will behave the same as if either #1 or #2 happened before the other, and exhibit no observable behavior besides the two volatile accesses---because boundedness of potentially concurrent conflicting operations is the quintessential property of atomic operations. So, it would be bizarre and extremely misleading if the implementors were to document that volatile accesses behave like `atomic_ref` accesses if they did not mean that the behavior of a program like this one is bounded. That would be like claiming to be a married bachelor.