On Sat, Mar 05, 2022 at 04:52:16PM +0000, Uecker, Martin via Liaison wrote:
> 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.

Thank you for taking the first step. I have added a comment giving an
example that I hope will help.

> > 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.

I am glad to hear that I am not the only one who feels this way. ;-)

> > 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...)

Well, if people find semantics of volatile annoying, just think how happy
they will be with the alternative, which is dealing with the semantics
of interrupts, traps, devices, etc. ;-)

                                                        Thanx, Paul

> 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_[hidden]
> > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > > Link to this post: http://lists.isocpp.org/liaison/2022/03/1022.php
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/03/1028.php