aboutsummaryrefslogtreecommitdiff
path: root/sysdeps/aarch64/dl-irel.h
diff options
context:
space:
mode:
authorJoseph Myers <josmyers@redhat.com>2025-03-27 10:44:44 +0000
committerJoseph Myers <josmyers@redhat.com>2025-03-27 10:44:44 +0000
commit75ad83f564b822de0f1f5fb6ed29f105373d3c49 (patch)
tree8da7ed5af54d8d514ca355cf37ac6958d1424e68 /sysdeps/aarch64/dl-irel.h
parentbe61b9493d38032519e596f282f9695667402c8d (diff)
downloadglibc-master.zip
glibc-master.tar.gz
glibc-master.tar.bz2
Implement C23 pownHEADmaster
C23 adds various <math.h> function families originally defined in TS 18661-4. Add the pown functions, which are like pow but with an integer exponent. That exponent has type long long int in C23; it was intmax_t in TS 18661-4, and as with other interfaces changed after their initial appearance in the TS, I don't think we need to support the original version of the interface. The test inputs are based on the subset of test inputs for pow that use integer exponents that fit in long long. As the first such template implementation that saves and restores the rounding mode internally (to avoid possible issues with directed rounding and intermediate overflows or underflows in the wrong rounding mode), support also needed to be added for using SET_RESTORE_ROUND* in such template function implementations. This required math-type-macros-float128.h to include <fenv_private.h>, so it can tell whether SET_RESTORE_ROUNDF128 is defined. In turn, the include order with <fenv_private.h> included before <math_private.h> broke loongarch builds, showing up that sysdeps/loongarch/math_private.h is really a fenv_private.h file (maybe implemented internally before the consistent split of those headers in 2018?) and needed to be renamed to fenv_private.h to avoid errors with duplicate macro definitions if <math_private.h> is included after <fenv_private.h>. The underlying implementation uses __ieee754_pow functions (called more than once in some cases, where the exponent does not fit in the floating type). I expect a custom implementation for a given format, that only handles integer exponents but handles larger exponents directly, could be faster and more accurate in some cases. I encourage searching for worst cases for ulps error for these implementations (necessarily non-exhaustively, given the size of the input space). Tested for x86_64 and x86, and with build-many-glibcs.py.
Diffstat (limited to 'sysdeps/aarch64/dl-irel.h')
0 files changed, 0 insertions, 0 deletions