> Not sure what such an absurd code example is supposed to show.
I had a few things in mind:
1. Highlight that it's not the wording change from "permissible" to "possible" that enables UB-based optimization - it's the interpretation of one of the behaviors the standard lists
2. It's the vagueness of "the situation" that's at the heart of the issue.
3. "Ignoring the situation completely" can produce the same result as "assuming UB never happens", contrary to your assertion (albeit subject to an interpretation that you disagree with)
(And absurd or not, similar code does show up in real life [0]. It's part of why -fno-delete-null-pointer-checks exists, after all).
> However, ignoring the situation completely in this case is emitting the code as written.
> "Ignoring the situation completely" means ignoring the fact that this is UB and just carrying on.
Wouldn't "emitting the code as written" or "ignoring the fact that this is UB and just carrying on" fall under the "to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message)"? If it does, why have the "ignoring the situation completely with unpredictable results" wording in the first place?
I'm not really convinced your definition of "ignoring the situation completely" is the only valid definition, either. Why wouldn't the standard's wording allow the interpretation in the example?
> That is the compiler's job: emit the code that the programmer wrote.
Because "That is the compiler's job: emit the code that the programmer wrote", and optimizing means the compiler is allowed to emit code the programmer did not write.
> If you can optimise without compromising the intended semantics of the code, go ahead.
And how does the compiler know what the "intended semantics" of the code are, if it isn't precisely what the programmer wrote?
> you will have to apply judgement
How is that compatible with "It is not the compiler's job to second guess the programmer and generate the code that it believes the programmer meant to write"? Applying judgement to guess what the programmer intended sounds exactly like "generating the code that [the compiler] believes the programmer meant to write".
I had a few things in mind:
1. Highlight that it's not the wording change from "permissible" to "possible" that enables UB-based optimization - it's the interpretation of one of the behaviors the standard lists
2. It's the vagueness of "the situation" that's at the heart of the issue.
3. "Ignoring the situation completely" can produce the same result as "assuming UB never happens", contrary to your assertion (albeit subject to an interpretation that you disagree with)
(And absurd or not, similar code does show up in real life [0]. It's part of why -fno-delete-null-pointer-checks exists, after all).
> However, ignoring the situation completely in this case is emitting the code as written.
> "Ignoring the situation completely" means ignoring the fact that this is UB and just carrying on.
Wouldn't "emitting the code as written" or "ignoring the fact that this is UB and just carrying on" fall under the "to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message)"? If it does, why have the "ignoring the situation completely with unpredictable results" wording in the first place?
I'm not really convinced your definition of "ignoring the situation completely" is the only valid definition, either. Why wouldn't the standard's wording allow the interpretation in the example?
> That is the compiler's job: emit the code that the programmer wrote.
Why bother with optimizations, then?
[0]: https://lwn.net/Articles/342330/