From bdccbfbc52d3f6957768a0b9d5bd7bc4c90f2744 Mon Sep 17 00:00:00 2001 From: Adhemerval Zanella Date: Fri, 31 Jan 2025 10:27:39 -0300 Subject: [PATCH] math: Fix log10p1f internal table value (BZ 32626) It was copied wrong from CORE-MATH. (cherry picked from commit c79277a16785c8ae96d821414f4d31d654a0177c) --- NEWS | 3 ++- math/auto-libm-test-in | 2 ++ math/auto-libm-test-out-log10p1 | 25 +++++++++++++++++++++++++ sysdeps/ieee754/flt-32/s_log10p1f.c | 2 +- 4 files changed, 30 insertions(+), 2 deletions(-) diff --git a/sysdeps/ieee754/flt-32/s_log10p1f.c b/sysdeps/ieee754/flt-32/s_log10p1f.c index 64deb1eeda5..4e11d55d49a 100644 --- a/sysdeps/ieee754/flt-32/s_log10p1f.c +++ b/sysdeps/ieee754/flt-32/s_log10p1f.c @@ -70,7 +70,7 @@ __log10p1f (float x) }; static const double tl[] = { - 0x1.562ec497ef351p-43, 0x1.b9476892ea99cp-8, 0x1.b5e909c959eecp-7, + -0x1.562ec497ef351p-43, 0x1.b9476892ea99cp-8, 0x1.b5e909c959eecp-7, 0x1.45f4f59ec84fp-6, 0x1.af5f92cbcf2aap-6, 0x1.0ba01a6069052p-5, 0x1.3ed119b99dd41p-5, 0x1.714834298a088p-5, 0x1.a30a9d98309c1p-5, 0x1.d41d51266b9d9p-5, 0x1.02428c0f62dfcp-4, 0x1.1a23444eea521p-4, From d85a7719536f4892f2b53d4594e18f6d096c2882 Mon Sep 17 00:00:00 2001 From: Adhemerval Zanella Date: Fri, 31 Jan 2025 10:34:32 -0300 Subject: [PATCH] math: Fix sinhf for some inputs (BZ 32627) The logic was copied wrong from CORE-MATH. --- math/auto-libm-test-in | 1 + math/auto-libm-test-out-sinh | 25 +++++++++++++++++++++++++ sysdeps/ieee754/flt-32/e_sinhf.c | 2 +- 3 files changed, 27 insertions(+), 1 deletion(-) diff --git a/sysdeps/ieee754/flt-32/e_sinhf.c b/sysdeps/ieee754/flt-32/e_sinhf.c index c007c7d1742..dee96fc7cbf 100644 --- a/sysdeps/ieee754/flt-32/e_sinhf.c +++ b/sysdeps/ieee754/flt-32/e_sinhf.c @@ -83,7 +83,7 @@ __ieee754_sinhf (float x) { /* |x| <= 0x1.250bfep-11 */ if (__glibc_unlikely (ux < 0x66000000u)) /* |x| < 0x1p-24 */ return fmaf (x, fabsf (x), x); - if (__glibc_unlikely (st.uarg == asuint (ux))) + if (__glibc_unlikely (st.uarg == ux)) { float sgn = copysignf (1.0f, x); return sgn * st.rh + sgn * st.rl; From cf88351b685da86667e17d344414a70696ac82f1 Mon Sep 17 00:00:00 2001 From: Adhemerval Zanella Date: Sun, 2 Feb 2025 16:57:49 -0300 Subject: [PATCH] math: Fix tanf for some inputs (BZ 32630) The logic was copied wrong from CORE-MATH. (cherry picked from commit 09e7f4d594b4308fbea18e3044148d67b59757c9) --- NEWS | 2 ++ math/auto-libm-test-in | 1 + math/auto-libm-test-out-tan | 25 +++++++++++++++++++++++++ sysdeps/ieee754/flt-32/s_tanf.c | 2 +- 4 files changed, 29 insertions(+), 1 deletion(-) diff --git a/sysdeps/ieee754/flt-32/s_tanf.c b/sysdeps/ieee754/flt-32/s_tanf.c index dfe56fc2a0f..5ee1d6f35e7 100644 --- a/sysdeps/ieee754/flt-32/s_tanf.c +++ b/sysdeps/ieee754/flt-32/s_tanf.c @@ -166,7 +166,7 @@ __tanf (float x) uint32_t sgn = t >> 31; for (int j = 0; j < array_length (st); j++) { - if (__glibc_unlikely (asfloat (st[j].arg) == ax)) + if (__glibc_unlikely (asuint (st[j].arg) == ax)) { if (sgn) return -st[j].rh - st[j].rl; From 66fc3bd75871d7239245c767abf44fb96d772f66 Mon Sep 17 00:00:00 2001 From: Aurelien Jarno Date: Thu, 6 Mar 2025 19:34:15 +0100 Subject: [PATCH] math: Remove an extra semicolon in math function declarations Commit 6bc301672bfbd ("math: Remove __XXX math functions from installed math.h [BZ #32418]") left an extra semicolon after macro expansion. For instance the ceil declaration after expansion is: extern double ceil (double __x) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));; This chokes very naive parsers like gauche c-wrapper. Fix that by removing that extra semicolon in the macro. Reviewed-by: Adhemerval Zanella (cherry picked from commit 443cb0b5f25129dd0f1e9f9101299d31c4700b7f) --- math/bits/mathcalls-macros.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/math/bits/mathcalls-macros.h b/math/bits/mathcalls-macros.h index 1ef07f1f58..321ae00ec8 100644 --- a/math/bits/mathcalls-macros.h +++ b/math/bits/mathcalls-macros.h @@ -34,7 +34,7 @@ #define __MATHCALLX(function,suffix, args, attrib) \ __MATHDECLX (_Mdouble_,function,suffix, args, attrib) #define __MATHDECLX(type, function,suffix, args, attrib) \ - __MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); + __MATHDECL_1(type, function,suffix, args) __attribute__ (attrib) #define __MATHDECL_1_IMPL(type, function, suffix, args) \ extern type __MATH_PRECNAME(function,suffix) args __THROW #define __MATHDECL_1(type, function, suffix, args) \ From 07288c7445bba747f65380066b1b5bdb2df5b630 Mon Sep 17 00:00:00 2001 From: John David Anglin Date: Tue, 25 Feb 2025 15:57:53 -0500 Subject: [PATCH 11] math: Add optimization barrier to ensure a1 + u.d is not reused [BZ #30664] A number of fma tests started to fail on hppa when gcc was changed to use Ranger rather than EVRP. Eventually I found that the value of a1 + u.d in this is block of code was being computed in FE_TOWARDZERO mode and not the original rounding mode: if (TININESS_AFTER_ROUNDING) { w.d = a1 + u.d; if (w.ieee.exponent == 109) return w.d * 0x1p-108; } This caused the exponent value to be wrong and the wrong return path to be used. Here we add an optimization barrier after the rounding mode is reset to ensure that the previous value of a1 + u.d is not reused. Signed-off-by: John David Anglin --- sysdeps/ieee754/dbl-64/s_fma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sysdeps/ieee754/dbl-64/s_fma.c b/sysdeps/ieee754/dbl-64/s_fma.c index 20f617b996e..42351c6b343 100644 --- a/sysdeps/ieee754/dbl-64/s_fma.c +++ b/sysdeps/ieee754/dbl-64/s_fma.c @@ -244,6 +244,9 @@ __fma (double x, double y, double z) /* Reset rounding mode and test for inexact simultaneously. */ int j = libc_feupdateenv_test (&env, FE_INEXACT) != 0; + /* Ensure value of a1 + u.d is not reused. */ + a1 = math_opt_barrier (a1); + if (__glibc_likely (adjust == 0)) { if ((u.ieee.mantissa1 & 1) == 0 && u.ieee.exponent != 0x7ff) From a900dbaf70f0a957f56b52caa69173592ad7596e Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Thu, 20 Feb 2025 07:08:26 +0800 Subject: [PATCH 09] x86 (__HAVE_FLOAT128): Defined to 0 for Intel SYCL compiler [BZ #32723] Intel compiler always defines __INTEL_LLVM_COMPILER. When SYCL is enabled by -fsycl, it also defines SYCL_LANGUAGE_VERSION. Since Intel SYCL compiler doesn't support _Float128: https://github.com/intel/llvm/issues/16903 define __HAVE_FLOAT128 to 0 for Intel SYCL compiler. This fixes BZ #32723. Signed-off-by: H.J. Lu Reviewed-by: Sam James (cherry picked from commit 5a4573be6f96ff49111bb6cae767676b5aafa7a8) --- sysdeps/x86/bits/floatn.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sysdeps/x86/bits/floatn.h b/sysdeps/x86/bits/floatn.h index d197cb10dde..adc7ed2e9e8 100644 --- a/sysdeps/x86/bits/floatn.h +++ b/sysdeps/x86/bits/floatn.h @@ -25,11 +25,15 @@ floating-point type with the IEEE 754 binary128 format, and this glibc includes corresponding *f128 interfaces for it. The required libgcc support was added some time after the basic compiler - support, for x86_64 and x86. */ + support, for x86_64 and x86. Intel SYCL compiler doesn't support + _Float128: https://github.com/intel/llvm/issues/16903 + */ #if (defined __x86_64__ \ ? __GNUC_PREREQ (4, 3) \ : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4))) \ - || __glibc_clang_prereq (3, 4) + || (__glibc_clang_prereq (3, 4) \ + && (!defined __INTEL_LLVM_COMPILER \ + || !defined SYCL_LANGUAGE_VERSION)) # define __HAVE_FLOAT128 1 #else # define __HAVE_FLOAT128 0 From 2cb04444b934e000a4e36c1876ef2bf03dd80d66 Mon Sep 17 00:00:00 2001 From: koraynilay Date: Sat, 22 Feb 2025 15:55:59 +0100 Subject: [PATCH 10] math: Fix `unknown type name '__float128'` for clang 3.4 to 3.8.1 (bug 32694) When compiling a program that includes using a clang version between 3.4 (included) and 3.8.1 (included), clang will fail with `unknown type name '__float128'; did you mean '__cfloat128'?`. This changes fixes the clang prerequirements macro call in floatn.h to check for clang 3.9 instead of 3.4, since support for __float128 was actually enabled in 3.9 by: commit 50f29e06a1b6a38f0bba9360cbff72c82d46cdd4 Author: Nemanja Ivanovic Date: Wed Apr 13 09:49:45 2016 +0000 Enable support for __float128 in Clang This fixes bug 32694. Signed-off-by: koraynilay Reviewed-by: H.J. Lu (cherry picked from commit 29803ed3ce420f01e7c567c97fc8945d5e5e5992) --- sysdeps/x86/bits/floatn.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sysdeps/x86/bits/floatn.h b/sysdeps/x86/bits/floatn.h index adc7ed2e9e8..4674165bd77 100644 --- a/sysdeps/x86/bits/floatn.h +++ b/sysdeps/x86/bits/floatn.h @@ -31,7 +31,7 @@ #if (defined __x86_64__ \ ? __GNUC_PREREQ (4, 3) \ : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4))) \ - || (__glibc_clang_prereq (3, 4) \ + || (__glibc_clang_prereq (3, 9) \ && (!defined __INTEL_LLVM_COMPILER \ || !defined SYCL_LANGUAGE_VERSION)) # define __HAVE_FLOAT128 1 @@ -93,7 +93,7 @@ typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__))); /* The type _Float128 exists only since GCC 7.0. */ # if !__GNUC_PREREQ (7, 0) \ || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) \ - || __glibc_clang_prereq (3, 4) + || __glibc_clang_prereq (3, 9) typedef __float128 _Float128; # endif