Am Samstag, den 05.03.2022, 07:56 -0800 schrieb Paul E. McKenney:
> On Fri, Mar 04, 2022 at 07:24:26PM +0000, Uecker, Martin via Liaison wrote:
> > FYI. Here is a summary of some time travel information
> > I collected and my position.
> >
> >
> > First, here is a quote from Jeff Law, the person who wrote the
> > optimization that eliminates code paths with UB for GCC:
> >
> > > Right. This is similar to some of the restrictions we deal with in
> > > the path isolation pass. Essentially we have a path, when traversed,
> > > would result in a *0. We would like to be able to find the edge
> > > upon-which the *0 is control dependent and optimize the test so that
> > > it always went to the valid path rather than the *0 path.
> > >
> > > The problem is there may be observable side effects on the *0 path
> > > between the test and the actual *0 -- including calls to nonreturning
> > > functions, setjmp/longjmp, things that could trap, etc. This case is
> > > similar. We can't back-propagate the non-null status through any
> > > statements with observable side effects.
> >
> > Nevertheless, I found this example where GCC reorders a volatile
> > store with respect to a potentially trapping instruction:
> >
> > https://godbolt.org/z/5vx9cPfM7
> >
> > But the comment I got from Richard Biener about this was that
> > they did not consider volatile stores to be observable.
> > (Martin Sebor produced a one-line fix for this, but it was
> > not clear whether such cases should/will be fixed)
>
> If anyone likes the idea of downstream device-driver bugs having a
> greater probability of bricking their computer's devices, then they
> should by all means continue remaining in denial on this topic. In the
> actual universe that we all live in, volatile stores can and really do
> have externally visible effects.
>
> So what is the best way to bring the standard and the implementations
> into alignment with the actual universe that we all live it?

The first step is to file bugs against the compilers.
A standard argument in the committee is that
compilers are always right, because "existing
practice", "the market has spoken", "our users
do not ask for this", "if a compiler does this,
it must be important for optimization" etc.
So evidence for problems is really helpful.

> Me, I would have naively expected that the following text already
> in the C standard would cover this case:
>
> In the abstract machine, all expressions are evaluated as
> specified by the semantics. An actual implementation need
> not evaluate part of an expression if it can deduce that its
> value is not used and that no needed side effects are produced
> (including any caused by calling a function or through volatile
> access to an object).

From the standard side this is clear that volatile
accesses are observable.

> So why wouldn't this paragraph prohibit reordering a volatile store with
> a potentially trapping instruction? Is the argument that it is OK to
> drop a "needed" side effect, but not an "observable" one?

The discussion now is not that volatile is not observable,
but that the UB can go backwards in time and "undo" previous
observable behavior. (In all other fields of engineering you
would be laughed out of court for proposing such dangerous
nonsense, but here...)

Martin


> Leaving aside the fact that volatile store are in fact observable by any
> reasonable living-in-this-universe definition of the word "observable".
>
> Thanx, Paul
>
> > MSVC appears to do time-travel:
> >
> > https://godbolt.org/z/1cd388sPj
> >
> > But then it does this also when the UB is not guaranteed
> > to happen, so this seems to be either a compiler bug
> > or some non-standard compilation mode:
> >
> > https://godbolt.org/z/8a8fTW8qP
> >
> >
> > The C standard says:
> >
> > "behavior, upon use of a nonportable or erroneous program
> > construct or of erroneous data, for which this document
> > imposes no requirements"
> >
> > To me the term "behavior" clearly implies something
> > happening at some point of time (either at run-time or
> > compile-time), and consequently "no requirements" only
> > applies to something at a point of time because the
> > words "for which" restrict to what this applies.
> >
> >
> > Martin
> >
>
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_lists.isocpp.org
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2022/03/1022.php