On Tue, Feb 23, 2021 at 1:12 PM Henry Miller via SG14 <sg14@lists.isocpp.org> wrote:
On Mon, Feb 22, 2021, at 16:28, Paul M. Bendixen via SG14 wrote:
If anyone can come up with a formulation of the "We don't know what we are getting.If it is possible to get atomicity we would love it, but we know that is rarely the case" sentence that doesn't sound completely idiotic, I'll credit whoever can come up with it with coauthor credits. :D
Seeing as nobody else has replied (at least not publicly)  I'll make my poor stab at this:

"It shall be implementation defined what conditions are required for the memory modification to be an atomic operation.  In all other situations, if the value in the memory changes between the read and write, then result of this operation is undefined.  Note that there is no requirement for any atomic updates."

FWIW, I interpreted the original request as asking for
- some informal language to put in the paper to describe why embedded programmers want this syntax to compile, assuming that we'd keep the old (lack of) formal semantics.
Not as asking for
- new standardese describing new semantics we'd like `volatile` to have.

The point of Paul's paper, as I understand it, is not to firm up the rules around volatile, but simply to undeprecate some syntactic constructs.

Situation in the 1990s through 2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics.
Situation post-2020: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it; but the implementation is formally encouraged to give you a deprecation diagnostic.
Situation Paul is trying to achieve: `vx += y;` compiles, with unclear formal semantics, but if you don't care about portability then you can use it and not get any diagnostics. (This is identical to the pre-2020 situation.)

Goal for the paper: Through informal language, convince WG21 that "Situation Paul is trying to achieve" is somehow better than "Situation post-2020."

I'm still extremely unconvinced myself — mainly due to lack of examples in the paper — but even with examples, you still need to explain why "add -Wno-deprecated to your makefile" isn't a reasonable medium-term solution. (ISTM that the long-term solution does have to be either to formalize the behavior per Henry's suggestion, or get programmers to stop using the syntax.)

–Arthur