diff options
author | Joseph Myers <josmyers@redhat.com> | 2024-06-17 16:31:49 +0000 |
---|---|---|
committer | Joseph Myers <josmyers@redhat.com> | 2024-06-17 16:31:49 +0000 |
commit | 7ec903e028271d029818378fd60ddaf6b76b89ac (patch) | |
tree | 29840403dc63c9c633e18e1d6607280ae59ce601 /elf/ifuncmain9pie.c | |
parent | 55eb99e9a9d840ba452b128be14d6529c2dde039 (diff) | |
download | glibc-7ec903e028271d029818378fd60ddaf6b76b89ac.tar.gz glibc-7ec903e028271d029818378fd60ddaf6b76b89ac.tar.xz glibc-7ec903e028271d029818378fd60ddaf6b76b89ac.zip |
Implement C23 exp2m1, exp10m1
C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
Diffstat (limited to 'elf/ifuncmain9pie.c')
0 files changed, 0 insertions, 0 deletions