On 19 September 2025 05:18:02 BST, Yongwei Wu via Std-Discussion <std-discussion_at_[hidden]> wrote:
>On Fri, 19 Sept 2025 at 04:59, Thiago Macieira via Std-Discussion
><std-discussion_at_[hidden]> wrote:
>>
>> On Thursday, 18 September 2025 03:55:01 Pacific Daylight Time David Brown via
>> Std-Discussion wrote:
>> > 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.
>>
>> One could reason the opposite. This is the case of the time-travelling UB: the
>> compiler is allowed to reason UBs never happen, so it is allowed to eliminate
>> all code paths that would have led there. That implies Clang implemented the
>> infinite loop as obscure way to write:
>> __builtin_unreachable();
>
>This is exactly the reason I dislike UB. Getting rid of code that has
>no side effects is one thing (David Brown kind of persuaded me),
>having a licence to do crazy things is another.
>
>It is better to have fews UBs. In my eyes, they have too much collateral damage.

I agree with this sentiment, and I think there might be room to allow the useful optimizations without the full-on UB.

It feels that the useful optimizations can be exhausted by allowing the abstract machine to do infinite unobservable operations in finite time, which would equate with eliding the loop, but keeping the semantics of the program intact before and after the loop.

We could consider making this defined behavior erroneous. Then compilers can insert a trap for provably infinite loops.