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?

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

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?

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