> 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.

An important point that needs to be said to make sure we are on the same page, is that nowhere the standard states the semantics of volatile access is to be defined in terms of atomic load/store.

The main clause describing volatile access doesn't imply any behavior related to antomics.

The clause 4.1.2.8 <https://eel.is/c++draft/intro.abstract#8.1>

    Accesses through volatile glvalues are
    evaluated strictly according to the rules
    of the abstract machine.

This doesn't mean volatile access must be implemented with atomic operations or somewhat emulate such.



-------- Original Message --------
From: jim x via Std-Discussion <std-discussion_at_[hidden]>
Sent: October 15, 2026 5:50:09 a.m. EDT
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: jim x <xmh970252187_at_[hidden]>, "std-discussion_at_[hidden]" <std-discussion_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]> *On
> Behalf Of *jim x via Std-Discussion
> *Sent:* Thursday, October 15, 2026 07:40
> *To:* Thiago Macieira <thiago_at_[hidden]>
> *Cc:* jim x <xmh970252187_at_[hidden]>; std-discussion_at_[hidden]
> *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_at_[hidden]>
> 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.
>
>

-- Julien Villemure
Sent from my Android device with K-9 Mail.