C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] time travel

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Fri, 4 Mar 2022 20:48:16 +0100
On 04/03/2022 20.24, 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)
>
>
> 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

Here's a web page that claims time-travel across observable
behavior for clang:

https://blog.regehr.org/archives/232

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

Same for C++:

undefined behavior
behavior for which this document imposes no requirements

but with a lengthy note:

[Note 1 to entry: Undefined behavior may be expected when this document omits any explicit definition of behavior
or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from
ignoring the situation completely with unpredictable results, to behaving during translation or program execution in
a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs
do not engender undefined behavior; they are required to be diagnosed. Evaluation of a constant expression (7.7)
never exhibits behavior explicitly specified as undefined in Clause 4 through Clause 15. — end note]


Jens

Received on 2022-03-04 19:48:21