I know this is crazy, and maybe an idea only Core could love, but we could define the abstract machine as being run inside another abstract machine.
(You might think this would then require infinite recursion, but possibly not. Also, infinity never stopped mathematicians.)

Volatile writes in the C++ abstract machine are just "normal" writes to a big unsigned char array in the outer abstract machine, the writes of which are visible to the rest of that machine.

On Wed, Apr 29, 2020 at 7:26 PM Patrice Roy via SG12 <sg12@lists.isocpp.org> wrote:
The need for a mechanism to ensure some operations are actually
performed, under whatever name we use, seems clear to me and has
been a recurring topic over the years. The work done by JF on
deprecating some uses of volatile also show (if we needed this to
be shown) that volatile lacked love... and, more formally, that
it was not sufficiently specified.

John Regehr has suggested in the past that, should be rethink
the volatile-related parts of the standard, one interesting avenue
could be to express volatile in terms of operations instead of
expressing them in terms of objects. If we took that path for
this mechanism (as was discussed in Cologne, from the paper
history; voting at 4 5 4 0 0 seems encouraging), we could start
to address the problems of adapting the abstract machine in terms
of a smaller subset of functions that impact the way we express
"as if", using some function that are not "as if" but have to be
taken literally by the compiler. This might localize the impact
of such changes to the sections where we discuss observable
behavior and fit in with std::observable.

Should we invest efforts in re-expressing aspects of the abstract
machine that discuss volatile in terms of volatile loads and
stores, and build facilities such as p1315 and n4534 from there?

Le mar. 28 avr. 2020 à 17:55, Jens Maurer via SG12 <sg12@lists.isocpp.org> a écrit :
On 28/04/2020 23.21, Miguel Ojeda wrote:
> # Jens Maurer
>> In order to solve these issues satisfactorily, we probably need a research effort approximately on the same level as improving our memory model for multi-threaded operations. This was a multi-year effort involving top-notch experts in the trade.
> Perhaps (I don't disagree with you on this, as you know), but the
> multi-threaded memory model is a good example of how something can
> work in practice, given programs using it were a thing decades before
> the memory model was formalized into the standard. Of course, it was
> not in the standard, but `memset_s` provides the example of something
> useful in the standard without being fully formal yet.

There's a bit of ambiguity here regarding the phrase "the standard".
My understanding is we're talking about the C++ standard, but
memset_s was never in that standard.

SG12 mailing list
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Link to this post: http://lists.isocpp.org/sg12/2020/04/0878.php
SG12 mailing list
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Link to this post: http://lists.isocpp.org/sg12/2020/04/0879.php

Be seeing you,