Date: Fri, 19 Sep 2025 09:02:00 +0200
On 18/09/2025 22:59, Thiago Macieira via Std-Discussion 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();
>
Certainly that is a valid interpretation for the compiler, given that
(until C++26) the loop was UB. And from the little I know of the
internals of clang, I expect the compiler did exactly as you suggest -
replace the loop with its internal representation for UB, exactly as it
would if you wrote "__builtin_unreachable();". I am simply suggesting
that in a situation like this, a clear halt is a bit more developer
friendly. It is a quality of implementation issue, not a suggestion
that clang was incorrect.
In many other cases, I support the use of UB for back-tracking and
letting the compiler gather more information that can lead to more
efficient code generation on the assumption that UB is never executed.
But it seems to me that there can be more helpful - less surprising -
alternative ways to deal with particular UB code constructs.
> 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();
>
Certainly that is a valid interpretation for the compiler, given that
(until C++26) the loop was UB. And from the little I know of the
internals of clang, I expect the compiler did exactly as you suggest -
replace the loop with its internal representation for UB, exactly as it
would if you wrote "__builtin_unreachable();". I am simply suggesting
that in a situation like this, a clear halt is a bit more developer
friendly. It is a quality of implementation issue, not a suggestion
that clang was incorrect.
In many other cases, I support the use of UB for back-tracking and
letting the compiler gather more information that can lead to more
efficient code generation on the assumption that UB is never executed.
But it seems to me that there can be more helpful - less surprising -
alternative ways to deal with particular UB code constructs.
Received on 2025-09-19 07:02:04