On Fri, 28 Oct 2022, Jeff Law via Gcc-patches wrote:

> Joseph, do you have bits in this space that are going to be landing soon, or
> is your C2X work focused elsewhere?  Are there other C2X routines we need to
> be proving builtins for?

I don't have any builtins work planned for GCC 13 (maybe adjustments to 
__builtin_tgmath semantics to match changes in C2X, but that's a keyword, 
not a built-in function).

See <https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603012.html> 
for my comments on (the tests in) this patch.

Lots of <math.h> functions could sensibly have built-in versions, whether 
for inline expansion, optimization for constant arguments or both.  Note 
that for those added from TS 18661-4, it will be more convenient to add 
glibc support once MPFR 4.2 is out so that gen-auto-libm-tests doesn't 
depend on an unreleased MPFR version, and likewise MPFR 4.2 will be needed 
for optimizing those functions for constant arguments.  But other 
highlights for which built-in functions might make sense in some cases 
include: issubnormal, iszero (see bugs 77925 / 77926, where Tamar 
Christina's patch needed to be reverted); probably the fromfp functions 
(but note that the interface in C2X is different from that in TS 18661-1 
and I haven't yet implemented those changes in glibc); the functions that 
round their result to a narrower type (supported as hardware operations on 
current POWER, I think); the functions bound to new maximum / minimum 
operations from IEEEE 754-2019 (some of which are supported by RISC-V 
instructions).  Also the <stdbit.h> functions; I expect to implement those 
for glibc largely using existing built-in functions, but more direct 
built-in function support for the <stdbit.h> names may make sense.

-- 
Joseph S. Myers
joseph@codesourcery.com