Re: reordering of trapping operations and volatile

[Martin Uecker <ma.uecker@gmail.com>]

Am Freitag, den 14.01.2022, 19:54 +0000 schrieb Jonathan Wakely:
> On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, <gcc@gcc.gnu.org> wrote:
> 
> > Hello,
> > 
> > On Thu, 13 Jan 2022, Martin Uecker wrote:
> > 
> > > > > >  Handling all volatile accesses in the very same way would be
> > > > > > possible but quite some work I don't see much value in.
> > > > > 
> > > > > I see some value.
> > > > > 
> > > > > But an alternative could be to remove volatile
> > > > > from the observable behavior in the standard
> > > > > or make it implementation-defined whether it
> > > > > is observable or not.
> > > > 
> > > > But you are actually arguing for making UB be observable
> > > 
> > > No, I am arguing for UB not to have the power
> > > to go back in time and change previous defined
> > > observable behavior.
> > 
> > But right now that's equivalent to making it observable,
> > because we don't have any other terms than observable or
> > undefined.  As aluded to later you would have to
> > introduce a new concept, something pseudo-observable,
> > which you then started doing.  So, see below.
> > 
> > > > That's
> > > > much different from making volatile not be
> > > > observable anymore (which  obviously would
> > > > be a bad idea), and is also much harder to
> > > 
> > > I tend to agree that volatile should be
> > > considered observable. But volatile is
> > > a bit implementation-defined anyway, so this
> > > would be a compromise so that implementations
> > > do not have to make all the implied changes
> > > if we revise the meaning of UB.
> > 
> > Using volatile accesses for memory mapped IO is a much stronger use-case
> > than your wish of using volatile accesses to block moving of UB as a
> > debugging aid, and the former absolutely needs some guarantees, so I don't
> > think it would be a compromise at all.  Mkaing volatile not be observable
> > would break the C language.
> > 
> > > > Well, what you _actually_ want is an implied
> > > > dependency between some UB and volatile accesses
> > > > (and _only_ those, not e.g. with other UB), and the
> > > > difficulty now is to define "some" and to create
> > > > the dependency without making that specific UB
> > > > to be properly observable.
> > > 
> > > Yes, this is what I actually want.
> > > 
> > > >  I think to define this
> > > > all rigorously seems futile (you need a new
> > > > category between observable  and UB), so it comes
> > > > down to compiler QoI on a case by case basis.
> > > 
> > > We would simply change UB to mean "arbitrary
> > > behavior at the point of time the erraneous
> > > construct is encountered at run-time"  and
> > > not "the complete program is invalid all
> > > together". I see no problem in specifying this
> > > (even in a formally precise way)
> > 
> > First you need to define "point in time", a concept which doesn't exist
> > yet in C.  The obvious choice is of course observable behaviour in the
> > execution environment and its specified ordering from the abstract
> > machine, as clarified via sequence points.  With that your "at the point
> > in time" becomes something like "after all side effects of previous
> > sequence point, but strictly before all side effects of next sequence
> > point".
> > 
> > But doing that would have very far reaching consequences, as already
> > stated in this thread.  The above would basically make undefined behaviour
> > be reliably countable, and all implementations would need to produce the
> > same counts of UB.  That in turn disables many code movement and
> > commonization transformations, e.g. this:
> > 
> > int a = ..., b = ...;
> > int x = a + b;
> > int y = a + b;
> > 
> > can't be transformed into "y = x = a + b" anymore, because the addition
> > _might_ overflow, and if it does you have two UBs originally but would
> > have one UB after.  I know that you don't want to inhibit this or similar
> > transformations, but that would be the result of making UB countable,
> > which is the result of forcing UB to happen at specific points in time.
> > So, I continue to see problems in precisely specifying what you want, _but
> > not more_.
> > 
> > I think all models in which you order the happening of UB with respect to
> > existing side effects (per abstract machine, so it includes modification
> > of objects!) have this same problem, it always becomes a side effect
> > itself (one where you don't specify what actually happens, but a side
> > effect nontheless) and hence becomes observable.
> > 
> 
> The C++ committee is currently considering this paper:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1494r2.html
> 
> I think this explicit barrier-like solution is better than trying to use
> volatile accesses to achieve something similar.

Can you explain why?  To me a solution which would make
it "just work" (and also fixes existing code) seems 
better than letting programmers jump through even 
more hoops, especially if only difficult corner
cases are affected.


Martin


> 
> 
> > 
> >