On Tue, May 23, 2023 at 7:52 AM Hans Boehm <boehm_at_[hidden]> wrote:

> As has been pointed out in some similar discussion, it's a bit tricky to
> define precisely what it means to "occur before an operation that has UB".
> I suspect we mostly mean "strongly happens before", but that leaves
> questions about where UB occurs. If I have
>
> volatile int v;
> int j= 1, k = 5;
> for (unsigned i = 0; i != 317; i += 14) {
> ++j;
> }
> for (unsigned i = 0; i != 317; i += 14) {
> ++k;
> v = i;
> }
>
> and the compiler merges the two loops, as intended, does that violate the
> concrete interpretation? The variable v is (incorrectly) updated, (long)
> before the first loop fails to terminate, and thus has UB(?)
>

Is it correct to say that a statement of the form "The implementation may
assume X", implies that if X is false, the program has undefined behavior?

If so, the condition X may not contain any reference to an undefined
operation, such as [intro.progress]/1 does not:

   "The implementation may assume that any thread will eventually [snip]"

Thus it is not rendered undefined behavior via [intro.abstract]/4, and as
such this kind of undefined behavior is out of scope of N3128. The
abstract interpretation and concrete interpretation are ill-posed with
regard to [intro.progress]/1.

Was N3128 intended to apply to all kinds of undefined behavior, or only
undefined behavior involving undefined operations?