On Wed, Oct 14, 2026 at 10:16 PM jim x via Std-Discussion <
std-discussion_at_[hidden]> 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()`.
>

For volatile? Nothing atomic at all. It means 'read/write always' don't
cache; and don't reorder accesses. That has nothing to do with atomic...
while atomic things are often used where volatile is, since volatile
indicates that the variable may change outside of the current execution
context, shared thread things probably denote it also with voltailte. But
volatile itself should never imply atomic. That you want it to imply
atomic to you is on you, not something the rest of the world needs or
wants. It doesn't matter if the variables aren't volatile - other than
{ int a = 1;
posChangeTo( &a );
while( a ) {
   // loop forever.
}
}

....

void posChangeTo( int *pi ) { /* probably toss to another thread, which has
a dleay... (*pi) = 0; }

the change will not necessarily change a in the first case, because the
compiler 'knows' nothing else outside that context will change A, it can
optimize that into while( true ) {}; That doesn't mean a `volatile int
a;` would be or should be atomic.


> On Wed, Oct 14, 2026 at 10:48 AM Brian Bi <bbi5291_at_[hidden]> wrote:
>
>> The wording isn't ambiguous. It explains the criteria for an
>> implementation to be considered conforming. Your question is not about
>> implementation conformance, so it at most identifies awkward phrasing, not
>> a genuine ambiguity.
>>
>> *Brian Bi*
>>
>> On Tue, Oct 13, 2026, 10:46 PM jim x via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> I'm trying to express the ambiguity I think about the wording.
>>>
>>> It doesn't say that accesses to volatiles *are* atomic.
>>>
>>>
>>> Yes. However, the standard simultaneously permits the implementation to
>>> define the semantics, which leaves a slot for implementations to define the
>>> parameterized part of the abstract machine. This leaves room for us to
>>> think about whether the operations associated with volatile glvalue
>>> are atomic or non-atomic* because they are parameterized by the
>>> implementations. *This is my confusion about the wording.
>>>
>>> On Tue, Oct 13, 2026 at 10:52 PM Thiago Macieira <thiago_at_[hidden]>
>>> wrote:
>>>
>>>> On Tuesday, 13 October 2026 01:43:01 Pacific Daylight Time jim x wrote:
>>>> > 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?
>>>>
>>>> It doesn't say that accesses to volatiles *are* atomic. Therefore, they
>>>> aren't
>>>> required to be and thus your example is a data race.
>>>>
>>>> jim, you've argued this over and over again. Everyone has the same
>>>> interpretation of the Standard except you and you keep arguing the same
>>>> thing
>>>> over and over again. What do you want to happen? Do you want a Standard
>>>> text
>>>> change to clarify things one way or another? If so, please propose it.
>>>> Are you
>>>> trying to argue with a vendor about their functionality?
>>>>
>>>> --
>>>> 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
>>>
>> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>