glibc/math, branch vdso

Do not set errno for overflowing NaN payload in strtod/nan (bug 32045)

2024-09-04T13:21:23Z

As reported in bug 32045, it's incorrect for strtod/nan functions to set errno based on overflowing payload (strtod should only set errno for overflow / underflow of its actual result, and potentially if nothing in the string can be parsed as a number at all; nan should be a pure function that never sets it). Save and restore errno around the internal strtoull call and add associated test coverage. Tested for x86_64.

Improve NaN payload testing

2024-09-04T13:20:18Z

There are two separate sets of tests of NaN payloads in glibc: * libm-test-{get,set}payload* verify that getpayload, setpayload, setpayloadsig and __builtin_nan functions are consistent in their payload handling. * test-nan-payload verifies that strtod-family functions and the not-built-in nan functions are consistent in their payload handling. Nothing, however, connects the two sets of functions (i.e., verifies that strtod / nan are consistent with getpayload / setpayload / __builtin_nan). Improve test-nan-payload to check actual payload value with getpayload rather than just verifying that the strtod and nan functions produce the same NaN. Also check that the NaNs produced aren't signaling and extend the tests to cover _FloatN / _FloatNx. Tested for x86_64.

added inputs giving large errors on x86_64 for new C23 functions

2024-08-07T12:28:46Z

These functions are exp10m1, exp2m1, log10p1, log2p1. Also regenerated ulps on x86_64. For each format, there are 4 values, one for each rounding mode. (For the intel96 format, there are 8 values, 4 for Intel hardware, and 4 for AMD hardware. However, regen-ulps was only run on Intel. It should be run in a separate patch on a AMD x86_64.) Reviewed-by: Adhemerval Zanella

support: Add FAIL test failure helper

2024-07-26T12:21:34Z

Add a FAIL test failure helper analogous to FAIL_RET, that does not cause the current function to return, providing a standardized way to report a test failure with a message supplied while permitting the caller to continue executing, for further reporting, cleaning up, etc. Update existing test cases that provide a conflicting definition of FAIL by removing the local FAIL definition and then as follows: - tst-fortify-syslog: provide a meaningful message in addition to the file name already added by ; 'support_record_failure' is already called by 'support_print_failure_impl' invoked by the new FAIL test failure helper. - tst-ctype: no update to FAIL calls required, with the name of the file and the line number within of the failure site additionally included by the new FAIL test failure helper, and error counting plus count reporting upon test program termination also already provided by 'support_record_failure' and 'support_report_failure' respectively, called by 'support_print_failure_impl' and 'adjust_exit_status' also respectively. However in a number of places 'printf' is called and the error count adjusted by hand, so update these places to make use of FAIL instead. And last but not least adjust the final summary just to report completion, with any error count following as reported by the test driver. - test-tgmath2: no update to FAIL calls required, with the name of the file of the failure site additionally included by the new FAIL test failure helper. Also there is no need to track the return status by hand as any call to FAIL will eventually cause the test case to return an unsuccesful exit status regardless of the return status from the test function, via a call to 'adjust_exit_status' made by the test driver. Reviewed-by: DJ Delorie

This patch adds larger ulp errors for the log2p1 function.

2024-07-22T06:54:23Z

Changes in v2: - added larger error for long double on AMD reported by Adhemerval (https://sourceware.org/pipermail/libc-alpha/2024-June/157755.html) Reviewed-by: Adhemerval Zanella

Implement C23 exp2m1, exp10m1

2024-06-17T16:31:49Z

C23 adds various 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.

Implement C23 log10p1

2024-06-17T13:48:13Z

C23 adds various function families originally defined in TS 18661-4. Add the log10p1 functions (log10(1+x): like log1p, but for base-10 logarithms). This is directly analogous to the log2p1 implementation (except that whereas log2p1 has a smaller underflow range than log1p, log10p1 has a larger underflow range). The test inputs are copied from those for log1p and log2p1, plus a few more inputs in that wider underflow range. Tested for x86_64 and x86, and with build-many-glibcs.py.

Implement C23 logp1

2024-06-17T13:47:09Z

C23 adds various function families originally defined in TS 18661-4. Add the logp1 functions (aliases for log1p functions - the name is intended to be more consistent with the new log2p1 and log10p1, where clearly it would have been very confusing to name those functions log21p and log101p). As aliases rather than new functions, the content of this patch is somewhat different from those actually adding new functions. Tests are shared with log1p, so this patch *does* mechanically update all affected libm-test-ulps files to expect the same errors for both functions. The vector versions of log1p on aarch64 and x86_64 are *not* updated to have logp1 aliases (and thus there are no corresponding header, tests, abilist or ulps changes for vector functions either). It would be reasonable for such vector aliases and corresponding changes to other files to be made separately. For now, the log1p tests instead avoid testing logp1 in the vector case (a Makefile change is needed to avoid problems with grep, used in generating the .c files for vector function tests, matching more than one ALL_RM_TEST line in a file testing multiple functions with the same inputs, when it assumes that the .inc file only has a single such line). Tested for x86_64 and x86, and with build-many-glibcs.py.

Don't provide scalb/significand _FloatN aliases [BZ #31760]

2024-05-22T13:10:54Z

scalb is a deprecated interface which was obsolescent in POSIX.1-2001, removed in POSIX.1-2008, never made to C standard. significant was originally from BSD and never made in any standard. Fix BZ #31760 by not providing _FloatN aliases for them. Signed-off-by: H.J. Lu Reviewed-by: Adhemerval Zanella

math: Add support for auto static math tests

2024-05-21T19:53:27Z

It basically copy the already in place rules for dynamic tests for auto-generated math functions for all support types. To avoid the need to duplicate .inc files, a .SECONDEXPANSION rules is adeed for the gen-libm-test.py generation. New tests are added on the new rules 'libm-test-funcs-auto-static', 'libm-test-funcs-noauto-static', and 'libm-test-funcs-narrow-static'; similar to the non-static counterparts. To avoid add extra build and disk requirement, the new math static tests are only enable with a new define 'build-math-static-tests'. Reviewed-by: H.J. Lu