qiurui
/
glibc
mirror of git://sourceware.org/git/glibc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
glibc/math/libm-test-pown.inc

151 lines
8.4 KiB
PHP
Raw Normal View History

Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* Test pown.
Copyright (C) 1997-2025 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<https://www.gnu.org/licenses/>. */
#include "libm-test-driver.c"
static const struct test_fL_f_data pown_test_data[] =
{
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, qnan_value, 0, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC),
TEST_fL_f (pown, -qnan_value, 0, 1, ERRNO_UNCHANGED|NO_TEST_MATHVEC),
TEST_fL_f (pown, snan_value, 0, qnan_value, INVALID_EXCEPTION|NO_TEST_MATHVEC),
TEST_fL_f (pown, -snan_value, 0, qnan_value, INVALID_EXCEPTION|NO_TEST_MATHVEC),
TEST_fL_f (pown, plus_infty, 1, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, -1, 0, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 1, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 11, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 1001, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 2, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 12, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 1002, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -1, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -11, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -1001, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -2, 0, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -12, 0, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -1002, 0, ERRNO_UNCHANGED),
TEST_fL_f (pown, qnan_value, 1, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, -qnan_value, 1, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, snan_value, 1, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, -snan_value, 1, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, qnan_value, -1, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, -qnan_value, -1, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, snan_value, -1, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, -snan_value, -1, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, qnan_value, 3, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, -qnan_value, 3, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, qnan_value, -3, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, -qnan_value, -3, qnan_value, NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
TEST_fL_f (pown, snan_value, 3, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, -snan_value, 3, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, snan_value, -3, qnan_value, INVALID_EXCEPTION),
TEST_fL_f (pown, -snan_value, -3, qnan_value, INVALID_EXCEPTION),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (x, 0) == 1. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, plus_infty, 0, 1, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0, 1, ERRNO_UNCHANGED),
TEST_fL_f (pown, 0, -1, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -11, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0xfffffe, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0xffffff, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0x1ffffffffffffeLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0x1fffffffffffffLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0x7ffffffffffffffeLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0x7fffffffffffffffLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -1, minus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -11L, minus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0xfffffe, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0xffffff, minus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x1fffffe, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x1ffffffffffffeLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x1fffffffffffffLL, minus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x3ffffffffffffeLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x7ffffffffffffffeLL, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
math: xfail some pown and compoundn tests for ibm128-libgcc 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>
2025-07-23 16:43:52 +00:00
TEST_fL_f (pown, minus_zero, -0x7fffffffffffffffLL, minus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE|XFAIL_ROUNDING_IBM128_LIBGCC),
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, 0, -2, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, 0, -0x1000000, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -2, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
TEST_fL_f (pown, minus_zero, -0x1000000, plus_infty, DIVIDE_BY_ZERO_EXCEPTION|ERRNO_ERANGE),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (+inf, y) == +inf for y > 0. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, plus_infty, 2, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, 0xffffff, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, 0x1fffffffffffffLL, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, 0x7fffffffffffffffLL, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, 0x1000000, plus_infty, ERRNO_UNCHANGED),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (+inf, y) == +0 for y < 0. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, plus_infty, -1, 0.0, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, -0xffffff, 0.0, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, -0x1fffffffffffffLL, 0.0, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, -0x7fffffffffffffffLL, 0.0, ERRNO_UNCHANGED),
TEST_fL_f (pown, plus_infty, -0x1000000, 0.0, ERRNO_UNCHANGED),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (-inf, y) == -inf for y an odd integer > 0. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, minus_infty, 27, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0xffffff, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0x1fffffe, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0x1fffffffffffffLL, minus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0x3ffffffffffffeL, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0x7ffffffffffffffeLL, plus_infty, ERRNO_UNCHANGED),
math: xfail some pown and compoundn tests for ibm128-libgcc 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>
2025-07-23 16:43:52 +00:00
TEST_fL_f (pown, minus_infty, 0x7fffffffffffffffLL, minus_infty, ERRNO_UNCHANGED|XFAIL_ROUNDING_IBM128_LIBGCC),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (-inf, y) == +inf for y > 0 and not an odd integer. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, minus_infty, 28, plus_infty, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, 0x1000000, plus_infty, ERRNO_UNCHANGED),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (-inf, y) == -0 for y an odd integer < 0. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, minus_infty, -3, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0xfffffe, plus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0xffffff, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x1fffffe, plus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x1ffffffffffffeLL, plus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x1fffffffffffffLL, minus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x3ffffffffffffeLL, plus_zero, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x7ffffffffffffffeLL, plus_zero, ERRNO_UNCHANGED),
math: xfail some pown and compoundn tests for ibm128-libgcc 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>
2025-07-23 16:43:52 +00:00
TEST_fL_f (pown, minus_infty, -0x7fffffffffffffffLL, minus_zero, ERRNO_UNCHANGED|XFAIL_ROUNDING_IBM128_LIBGCC),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
/* pown (-inf, y) == +0 for y < 0 and not an odd integer. */
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
TEST_fL_f (pown, minus_infty, -2, 0.0, ERRNO_UNCHANGED),
TEST_fL_f (pown, minus_infty, -0x1000000, 0.0, ERRNO_UNCHANGED),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
Correct test descriptors in libm-test-pown.inc 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.
2025-05-01 22:28:59 +00:00
AUTO_TESTS_fL_f (pown),
Implement C23 pown 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.
2025-03-27 10:44:44 +00:00
};
static void
pown_test (void)
{
ALL_RM_TEST (pown, 0, pown_test_data, RUN_TEST_LOOP_fL_f, END);
}
static void
do_test (void)
{
pown_test ();
}
/*
* Local Variables:
* mode:c
* End:
*/