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 jos...@codesourcery.com
