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.
Thanks,
Richard.
