On 18/09/2025 08:41, Yongwei Wu wrote:

> I might accept the do-nothing loops can be eliminated, if we could not
> find a compromise between the theoretical model and the naïve
> programmers' view. However, it is still different from the pre-C++26
> UB of empty loops. In that specific case, not only was the empty loop
> eliminated, but the program would crash as well, because the compiler
> was in the Schrödingerian state of thinking two incompatible things:
> the loop would finish; the code after the loop would be unreachable.
> As the code was "undefined", one could not even blame the compiler.
>
> So, the forward progress guarantee promises more dangerous things than
> what you described, as far as I understand it.
>

Yes, what I described was being able to eliminate do-nothing loops even
if they are infinite - not saying that do-nothing infinite loops are UB.

Of course, even prior to C++26, compilers have been free to eliminate
do-nothing infinite loops, or to implement them as a tight infinite loop
- when the standards don't define a behaviour, compilers writers can do
so. gcc has always implemented "while (true) ;" loops as a tight
infinite loop - as required by C, and not C++26. clang, it seems, did
not do so until clang 19 (the first version that accepts "-std=c++26").
clang 18 and earlier would generate nothing at all - leaving execution
to fall through into whatever bytes happen to come after the function's
object code in memory. That was allowed by the C++ standards, but seems
to me to be a poor choice for the compiler - if your code executes UB,
compilers have no way to give you the "right" results (because there
/are/ no correct answers), but it is often possible to reduce how bad
things can get. A tight infinite loop (like gcc) would be reasonable,
as would an "UB" or trap instruction that guarantees a program halt on a
hosted OS like Linux is a better choice.