diff options
author | Joseph Myers <josmyers@redhat.com> | 2025-03-27 10:44:44 +0000 |
---|---|---|
committer | Joseph Myers <josmyers@redhat.com> | 2025-03-27 10:44:44 +0000 |
commit | 75ad83f564b822de0f1f5fb6ed29f105373d3c49 (patch) | |
tree | 8da7ed5af54d8d514ca355cf37ac6958d1424e68 /sysdeps/powerpc/powerpc32/power6/fpu/multiarch/Implies | |
parent | be61b9493d38032519e596f282f9695667402c8d (diff) | |
download | glibc-master.zip glibc-master.tar.gz glibc-master.tar.bz2 |
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/powerpc/powerpc32/power6/fpu/multiarch/Implies')
0 files changed, 0 insertions, 0 deletions