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.
Jakub
