> On 8 Sep 2025, at 12:46, Richard Biener <richard.guent...@gmail.com> wrote:
>
> On Mon, Sep 8, 2025 at 1:04 PM Ville Voutilainen
> <ville.voutilai...@gmail.com> wrote:
>>
>> On Mon, 8 Sept 2025 at 13:54, Richard Biener <richard.guent...@gmail.com>
>> wrote:
>>> That said, I see no point in std::observable_checkpoint to be represented
>>> in the IL at all if all it is is to cater to FUD around what compilers might
>>> think is a correct transform?
>>
>> It's not just to cater to FUD. I have seen Clang remove a complete CFG
>> edge that lead to a non-return from
>> a non-void function. If observable_checkpoint works correctly, the
>> debug prints my junior colleague added trying
>> to see how the execution flows would've worked when used with the
>> checkpoint, whereas clang happily
>> removed them along with everything else on that CFG edge proven to
>> lead to UB. I am unable to find
>> any specification rationale that would make such a transformation
>> incorrect, and with observable_checkpoint,
>> that situation changes.
>
> So the situation is sth like
>
> int foo ()
> {
> printf ("what?");
> }
>
> that was optimized away completely by clang and you want to fix that with
>
> int foo ()
> {
> printf ("what?");
> std::observable_checkpoint ();
> }
>
> ? But this is again a clang bug. printf could call
> std::observable_checkpoint () itself, no?
> Even if clang can conclude that printf("what?") always will return
> normally there's a
> side-effect to be preserved (printing 'what?').
>
> If this isn't the actual testcase, can you share it? I do not see
> clang (version 19)
> optimizing away the printf in the above testcase.
I also do not think it is all FUD - although clang is/was more likely
to exhibit it. In the discussions there have been many proposed
cases in which a problem could occur - most of them are hard
to reproduce (even if the compiler might technically do the thing
in practice GCC does not).
—— however...
For the testcase attached to the patch.
Do we consider that the addition to x is considered observable?
- because it is now extern and therefore can be seen by some
other TU,
Then is it a bug in GCC that we elide that increment when it is
followed by UB?
===
we can also have things like
char *p = something;
if (p == nullptr)
{
__builtin_printf (“bad pointer\n”);
__builtin_abort ();
}
….
some UB….
which gets reduced to an unconditional print and abort.
(I agree that this is allowed, but it is unexpected to many users)
that kind of check can also be guarded.
Iain
> Thanks,
> Richard.
