On Thu, Sep 4, 2025 at 7:17 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Thu, Sep 04, 2025 at 05:59:25PM +0100, Iain Sandoe wrote:
> > PR c++/119060
> >
> > gcc/ChangeLog:
> >
> > * builtins.cc (expand_builtin): Handle BUILT_IN_OBSERVABLE_CHKPT.
> > * builtins.def (BUILT_IN_OBSERVABLE_CHKPT): New.
> >
> > gcc/c-family/ChangeLog:
> >
> > * c-common.cc: Add __builtin_observable_checkpoint.
> > * c-common.h (enum rid): Add RID_BUILTIN_OBSERVABLE_CHKPT.
> >
> > gcc/cp/ChangeLog:
> >
> > * cp-objcp-common.cc (names_builtin_p): Handle
> > BUILT_IN_OBSERVABLE_CHKPT.
> > * cxxapi-data.csv: Add observable_checkpoint to <utility>.
> > * parser.cc (cp_parser_postfix_expression): Handle
> > __builtin_observable_checkpoint.
> > * std-name-hint.gperf: Add observable_checkpoint to <utility>.
> > * std-name-hint.h: Regenerate.
>
> I don't understand why you need to both define it as a builtin and
> as a keyword. If it is a builtin, then the cp/cp-objcp-common.cc
> and c-family and cp/parser.cc changes make no sense.
>
> Another question is if ATTR_NOTHROW_LEAF_LIST are the right flags for it
> (as opposed to ATTR_NOTHROW_LIST), i.e. how much as an optimization
> barrier we want to treat it.
>
> And lastly whether it is ok to throw it away during RTL expansion,
> or whether it needs to be kept in some form.
>
> My initial thoughts on how to implement it would be
> namespace std {
> inline [[__gnu__::__noinline__, __gnu__::__noipa__]] void
> observable_checkpoint() {}
> }
> i.e. keep it as a call to an optimization barrier until runtime
> but don't really do anything at that point.
That's probably equivalent to the builtin. I'll note that both are
less strong of a barrier than setjmp() or longjmp() which we
arrange to have abnormal incoming/outgoing edges so even
register computations cannot be moved across them. So
for extra barrier-ness you want to add returns_twice.
Richard.
>
> Jakub
>
