Since you said the volatile access in the program is non-atomic, you should refer to the relevant definition to clarify why the volatile access is not atomic regardless of how semantics are given. Unfortunately, you cannot cite the defintion because the standard doesn't have a clear definition of "atomic operations".
That is because atomic is a standard word in programming, It means something that can not suffer from race conditions amid an unexpected context switch. You can't define something like that unless it originates from the language or is a key part of it. It's like asking to define borrowed words in a language. There is no doubt that this is imperfect, a good example is how some words in german make the letter "v" sound as an english "v", but it is something that you have to deal with as a part of understanding a language, infact, that process is called research. 
Coming back to why non-atomic is volatile; they are volatile because the definition of non volatile is that the compiler promises to not erase the side effects, other than that it is as non atomic as any other operation. You can't call something red just because you can't find a way to define red, like at some point even natural numbers cant be further simplified from a few axioms and propositions.
This email reminds me of how I was fixated on my points instead of taking enough time to understand what people are trying to explain to me. I get that I was just a kid, but yeah, just take your time.

On Tue, Oct 20, 2026 at 12:01 PM jim x via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
What I was expecting is clarification, you said you wanted to change the wording to fix a perceived problem you have with it, I asked what wording do you feel it would be “correct”.

Since you said the volatile access in the program is non-atomic, you should refer to the relevant definition to clarify why the volatile access is not atomic regardless of how semantics are given. Unfortunately, you cannot cite the defintion because the standard doesn't have a clear definition of "atomic operations".

On Fri, Oct 16, 2026 at 6:07 PM Tiago Freire <tmiguelf@hotmail.com> wrote:

What does that have to do with volatile?

What I was expecting is clarification, you said you wanted to change the wording to fix a perceived problem you have with it, I asked what wording do you feel it would be “correct”.

Now what you are saying is “there is a problem with something else (atomics now), please fix it”.

That’s not explaining the problem, you haven’t explained the problem. Claiming that there is one, and then asking others to fix it, is not helpful.

 

Just FYI. I don’t have to do anything. Nobody has to do anything for you here.

 

I don’t see this conversation being productive any further. I would say “if you have a concrete problem, then write a proposal and submit it”, but let’s be honest, that ain’t going to happen.

So, I guess that’s what I’m going to do about this thread, I’m just going to ignore it.

 

From: jim x <xmh970252187@gmail.com>
Sent: Friday, October 16, 2026 11:18
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: std-discussion@lists.isocpp.org; Thiago Macieira <thiago@macieira.org>
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?

 

Define what "atomic" is; this is also asked in LWG2506.

 

On Thu, Oct 15, 2026 at 7:04 PM Tiago Freire <tmiguelf@hotmail.com> wrote:

What is the exact wording you are proposing?

 

From: jim x <xmh970252187@gmail.com>
Sent: Thursday, October 15, 2026 11:50
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: std-discussion@lists.isocpp.org; Thiago Macieira <thiago@macieira.org>
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?

 

If yes, then I think we already explained why we can’t make data-races with volatile to be implementation-defined, because that would force the implementation to pick a behavior with quite negative consequences, and we don’t want that.

 

I agree that the behavior of the program in my question should be intended to be undefined behavior. What I don't agree with is that the wording in the current standard is clear enough to help us infer that the program contains a data race, especially since the standard doesn't formally define the term "atomic" appearing in [intro.race] p17. 

I think the wording should be rephrased to embody the meaning that the operations at `#1` and `#2` are non-atomic regardless of how the implementations give the semantics; for example, these operations are deemed non-atomic even though the implementation specifies them as  std::atomic_ref::load() / store() for their semantics. 

 

 

 

On Thu, Oct 15, 2026 at 3:26 PM Tiago Freire <tmiguelf@hotmail.com> wrote:

If an implementation makes volatile to have the same semantics as an atomic, then I would expect that in that implementation volatile would have the same properties as an atomic.

Not that this helps anyone in any way, as if I was to write code that needed to rely on the specific implementation of volatile = atomic, I would have just used atomic in the first place.

 

Also note that the consequences are irrelevant to the original example (source code) you provided would still have an undetermined result even with atomics.

 

What is the point of all of this anyways? Are you trying to change the text?

 

If yes, then I think we already explained why we can’t make data-races with volatile to be implementation-defined, because that would force the implementation to pick a behavior with quite negative consequences, and we don’t want that. And if you think this observation is not quite correct, then I think you need to properly formalize a proposal, because nobody seems to agree with you in this informal email exchange format. Maybe we don’t get it, and the devil is in the details, and you need to be very specific about it.

 

If no, then what is the point of this conversation?

 

 

From: Std-Discussion <std-discussion-bounces@lists.isocpp.org> On Behalf Of jim x via Std-Discussion
Sent: Thursday, October 15, 2026 07:40
To: Thiago Macieira <thiago@macieira.org>
Cc: jim x <xmh970252187@gmail.com>; std-discussion@lists.isocpp.org
Subject: Re: [std-discussion] Is this program undefined-behavior or implementation-defined behavior?

 

I don't think that there's anywhere that an IB choice can make what is otherwise UB not so.

 

If the standard deems a program to have undefined behavior, then regardless of how an implementation guarantees its specific behavior, the program is undefined from the perspective of the standard—there is no dispute about this. However, the crux of the problem is that ambiguity arises in the very process of applying the standard's rules to determine whether the program is undefined in the first place.

The premise of your claim that the program in my question is undefined is that it contains a data race, and whether a program contains a data race is determined by the rules in [intro.race] p17. One of the conditions in paragraph 17 is "at least one of which is not atomic"—if both operations are atomic, then no data race exists. Meanwhile, another rule in the standard states: "The semantics of an access through a volatile glvalue are implementation-defined", which means the semantics of the access depend on the specific implementation and serve as an open parameter within the abstract machine.

The question, then, is this: if an implementation defines these operations to be identical to std::atomic_ref::load() / store(), does the condition "at least one of which is not atomic" in [intro.race] p17 evaluate to false? In that case, is the program still undefined? This is the core issue, whereas your initial claim that the program is simply undefined completely skipped the process of determining whether a data race actually exists.

 

 

On Thu, Oct 15, 2026 at 1:24 PM Thiago Macieira <thiago@macieira.org> wrote:

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.

--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion