Date: Sat, 20 May 2023 00:53:09 +1000
The relevant passage from the C++ standard is [intro.abstract]/4:
"A conforming implementation executing a well-formed program shall produce
the same observable behavior as one of the possible executions of the
corresponding instance of the abstract machine with the same program and
the same input. However, if any such execution contains an undefined
operation, this document places no requirement on the implementation
executing that program with that input (*not even with regard to operations
preceding the first undefined operation*)."
https://eel.is/c++draft/intro.abstract#4
So this uses what N3128 refers to as the abstract interpretation.
Changing to the concrete interpretation would render numerous existing
practice compiler optimizations non-conformant as N3128 points out.
N3128 claims that such optimizations do not provide significant benefit in
practice:
"While the concrete interpretations seems to substantially limit the
optimizations that can be performed relative to the abstract interpretation
of UB, the difference is actually very small and does not seem to affect
common optimizations (such as the one in the example above)."
An example of evidence to support this claim would be empirical analysis of
an implementation with abstract interpretation optimizations turned on and
off and run against a wide range of profiled production programs, showing
that the performance improvement is indeed very small.
On Fri, May 19, 2023 at 10:42 PM Martin Uecker via Liaison <
liaison_at_[hidden]> wrote:
>
>
> Hi everybody,
>
> the C UB study group recommends to clarify that run-time
> UB affects the concrete operations upon use of the
> operation which has UB (concrete interpretation),
> but does not make those programs have no semantics at all
> (abstract interpretation).
>
> I wrote a paper about this:
>
> https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3128.pdf
>
>
> The short summary is:
>
> 1.) The abtract interpretation that makes programs have
> no semantics is not required for existing optimizations.
>
> 2.) With the concrete interpretation one can show
> partial programm correctness up to the point where
> the operation that has UB is encountered.
>
> 3.) The concrete interpretation makes it possible to
> formulate additional requirements for programs that
> have run-time UB (e.g. Annex L in C, or for
> concurrent programms as suggested in Hans Boehm's
> paper). As such it is a prerequesite to make further
> progress in limiting the consequences of UB.
>
>
> Any thoughts about this? I think C++ could simply
> do the same. But I assume there are many different
> opinions about this.
>
>
> Martin
>
>
>
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Searchable archives: http://lists.isocpp.org/liaison/2023/05/index.php
>
"A conforming implementation executing a well-formed program shall produce
the same observable behavior as one of the possible executions of the
corresponding instance of the abstract machine with the same program and
the same input. However, if any such execution contains an undefined
operation, this document places no requirement on the implementation
executing that program with that input (*not even with regard to operations
preceding the first undefined operation*)."
https://eel.is/c++draft/intro.abstract#4
So this uses what N3128 refers to as the abstract interpretation.
Changing to the concrete interpretation would render numerous existing
practice compiler optimizations non-conformant as N3128 points out.
N3128 claims that such optimizations do not provide significant benefit in
practice:
"While the concrete interpretations seems to substantially limit the
optimizations that can be performed relative to the abstract interpretation
of UB, the difference is actually very small and does not seem to affect
common optimizations (such as the one in the example above)."
An example of evidence to support this claim would be empirical analysis of
an implementation with abstract interpretation optimizations turned on and
off and run against a wide range of profiled production programs, showing
that the performance improvement is indeed very small.
On Fri, May 19, 2023 at 10:42 PM Martin Uecker via Liaison <
liaison_at_[hidden]> wrote:
>
>
> Hi everybody,
>
> the C UB study group recommends to clarify that run-time
> UB affects the concrete operations upon use of the
> operation which has UB (concrete interpretation),
> but does not make those programs have no semantics at all
> (abstract interpretation).
>
> I wrote a paper about this:
>
> https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3128.pdf
>
>
> The short summary is:
>
> 1.) The abtract interpretation that makes programs have
> no semantics is not required for existing optimizations.
>
> 2.) With the concrete interpretation one can show
> partial programm correctness up to the point where
> the operation that has UB is encountered.
>
> 3.) The concrete interpretation makes it possible to
> formulate additional requirements for programs that
> have run-time UB (e.g. Annex L in C, or for
> concurrent programms as suggested in Hans Boehm's
> paper). As such it is a prerequesite to make further
> progress in limiting the consequences of UB.
>
>
> Any thoughts about this? I think C++ could simply
> do the same. But I assume there are many different
> opinions about this.
>
>
> Martin
>
>
>
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Searchable archives: http://lists.isocpp.org/liaison/2023/05/index.php
>
Received on 2023-05-19 14:53:23