Am Samstag, dem 20.05.2023 um 00:53 +1000 schrieb Andrew Tomazos:
> 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.

Yes.

> Changing to the concrete interpretation would render numerous existing practice compiler optimizations non-conformant as N3128 points out.

N3128 points out the exact opposite: that we are not aware of
any relevant compiler optimization affected by this. The only
exception we know of are some re-ordering of volatile accesses,
which seem undesirable and dangerous.

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

This does not say those optimization do not provide significant benefits.
It says that there are only a small difference in the opportunities for
optimization opened up by the abstract interpretation but not the
concrete. All optimization that provide practical advantages that
we could identify are enabled by both interpretations.

Martin



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