It fixes ce488f7c1615bc2f6fe96ff4d51456e470aa5805 which updated the out files without using gen-auto-libm-tests.c instructions. Checked on powerpc64le-linux-gnu. Tested-by: Andreas K. Huettel <dilfridge@gentoo.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
On powerpc math/test-ibm128-pown shows below failures: testing long double (without inline functions) infinity has wrong sign. Failure: Test: pown_downward (-inf, 0x7fffffffffffffffLL) Result: is: inf inf should be: -inf -inf Failure: Test: pown_downward (-0, 9223372036854775807LL) Result: is: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 should be: -0.00000000000000000000000000000000e+00 -0x0.000000000000000000000000000p+0 difference: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 ulp : 0.0000 max.ulp : 16.0000 Failure: pown_downward (-0x1p+0, 9223372036854775807LL): Exception "Invalid operation" set Failure: pown_downward (-0x1p+0, 9223372036854775807LL): errno set to 34, expected 0 (unchanged) Failure: Test: pown_downward (-0x1p+0, 9223372036854775807LL) Result: is: qNaN should be: -1.00000000000000000000000000000000e+00 -0x1.000000000000000000000000000p+0 infinity has wrong sign. Failure: Test: pown_towardzero (-0, -0x7fffffffffffffffLL) Result: is: inf inf should be: -inf -inf infinity has wrong sign. Failure: Test: pown_towardzero (-inf, 0x7fffffffffffffffLL) Result: is: inf inf should be: -inf -inf Failure: Test: pown_towardzero (-inf, -0x7fffffffffffffffLL) Result: is: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 should be: -0.00000000000000000000000000000000e+00 -0x0.000000000000000000000000000p+0 difference: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 ulp : 0.0000 max.ulp : 16.0000 Failure: Test: pown_towardzero (-0, 9223372036854775807LL) Result: is: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 should be: -0.00000000000000000000000000000000e+00 -0x0.000000000000000000000000000p+0 difference: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 ulp : 0.0000 max.ulp : 16.0000 Failure: pown_towardzero (-0x1p+0, -9223372036854775807LL): Exception "Invalid operation" set Failure: pown_towardzero (-0x1p+0, -9223372036854775807LL): errno set to 34, expected 0 (unchanged) Failure: Test: pown_towardzero (-0x1p+0, -9223372036854775807LL) Result: is: qNaN should be: -1.00000000000000000000000000000000e+00 -0x1.000000000000000000000000000p+0 Failure: pown_towardzero (-0x1p+0, 9223372036854775807LL): Exception "Invalid operation" set Failure: pown_towardzero (-0x1p+0, 9223372036854775807LL): errno set to 34, expected 0 (unchanged) Failure: Test: pown_towardzero (-0x1p+0, 9223372036854775807LL) Result: is: qNaN should be: -1.00000000000000000000000000000000e+00 -0x1.000000000000000000000000000p+0 infinity has wrong sign. Failure: Test: pown_upward (-0, -0x7fffffffffffffffLL) Result: is: inf inf should be: -inf -inf Failure: Test: pown_upward (-inf, -0x7fffffffffffffffLL) Result: is: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 should be: -0.00000000000000000000000000000000e+00 -0x0.000000000000000000000000000p+0 difference: 0.00000000000000000000000000000000e+00 0x0.000000000000000000000000000p+0 ulp : 0.0000 max.ulp : 16.0000 Failure: pown_upward (-0x1p+0, -9223372036854775807LL): Exception "Invalid operation" set Failure: pown_upward (-0x1p+0, -9223372036854775807LL): errno set to 34, expected 0 (unchanged) Failure: Test: pown_upward (-0x1p+0, -9223372036854775807LL) Result: is: qNaN should be: -1.00000000000000000000000000000000e+00 -0x1.000000000000000000000000000p+0 Likewise, math/test-ibm128-compoundn shows below failure: testing long double (without inline functions) Failure: compoundn_upward (0xf.ffffffffffff8p+1020, 1LL): Exception "Overflow" set Failure: compoundn_upward (0xf.ffffffffffff8p+1020, 1LL): errno set to 34, expected 0 (unchanged) Failure: Test: compoundn_upward (0xf.ffffffffffff8p+1020, 1LL) Result: is: inf inf should be: 1.79769313486231570814527423731707e+308 0x1.fffffffffffff00000000000008p+1023 Signed-off-by: Sachin Monga <smonga@linux.ibm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Use more inclusive language in generated sources. Reviewed-by: Florian Weimer <fweimer@redhat.com>
Implement double and single precision variants of the C23 routine atan2pi for both AdvSIMD and SVE. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine atanpi for both AdvSIMD and SVE. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine asinpi for both AdvSIMD and SVE. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine acospi for both AdvSIMD and SVE. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
C23 adds various <math.h> function families originally defined in TS 18661-4. Add the rootn functions, which compute the Yth root of X for integer Y (with a domain error if Y is 0, even if X is a NaN). The integer 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. As with pown and compoundn, I strongly encourage searching for worst cases for ulps error for these implementations (necessarily non-exhaustively, given the size of the input space). I also expect a custom implementation for a given format could be much faster as well as more accurate, although the implementation is simpler than those for pown and compoundn. This completes adding to glibc those TS 18661-4 functions (ignoring DFP) that are included in C23. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118592 regarding the C23 mathematical functions (not just the TS 18661-4 ones) missing built-in functions in GCC, where such functions might usefully be added. Tested for x86_64 and x86, and with build-many-glibcs.py.
C23 adds various <math.h> function families originally defined in TS 18661-4. Add the compoundn functions, which compute (1+X) to the power Y for integer Y (and X at least -1). The integer 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. Note that these functions are "compoundn" with a trailing "n", *not* "compound" (CORE-MATH has the wrong name, for example). As with pown, I strongly encourage searching for worst cases for ulps error for these implementations (necessarily non-exhaustively, given the size of the input space). I also expect a custom implementation for a given format could be much faster as well as more accurate (I haven't tested or benchmarked the CORE-MATH implementation for binary32); this is one of the more complicated and less efficient functions to implement in a type-generic way. As with exp2m1 and exp10m1, this showed up places where the powerpc64le IFUNC setup is not as self-contained as one might hope (in this case, without the changes specific to powerpc64le, there were undefined references to __GI___expf128). Tested for x86_64 and x86, and with build-many-glibcs.py.
While working on implementing compoundn, I noticed that libm-test-pown.inc was wrongly using TEST_ff_f and AUTO_TESTS_ff_f when the actual types involved meant fL_f should be used instead of ff_f; fix to use the correct descriptor strings for pown. (These strings affect how gen-libm-test.py generates a C file in some cases. The structure type test_fL_f_data for expected results and the use of RUN_TEST_LOOP_fL_f in the ALL_RM_TEST call were already correct.) Tested for x86_64. The generated libm-test-pown.c was actually unchanged, but the old descriptor strings were still logically incorrect.