user/sven/glibc.git/math/math.h, branch master

Revert "x86: Do not use __builtin_fpclassify for _Float64x/long double"

2026-01-14T17:33:20Z

This reverts commit 50112103993b042f52fb6afb0e4eee24fe4cb9af. It breaks libstdc++ and other languages bootstrap. Reviewed-by: Carlos O'Donell

Revert "x86: Do not use __builtin_isinf_sign for _Float64x/long double"

2026-01-14T17:33:16Z

This reverts commit 999cd617cb7e40a2fa719e91fe1028c853ae14d5. It breaks libstdc++ and other languages bootstrap. Reviewed-by: Carlos O'Donell

Update copyright dates with scripts/update-copyrights

2026-01-01T21:42:29Z

x86: Do not use __builtin_isinf_sign for _Float64x/long double

2025-12-22T18:55:20Z

Neither gcc [1] nor clang [2] handles pseudo-normal numbers correctly with the __builtin_isinf_sign, so disable its usage for _Float64x and long double types. This only affects x86, so add a new define __FP_BUILTIN_ISINF_SIGN_DENORMAL to gate long double and related types to the libc function instead. It fixes the regression on test-ldouble-isinf when built with clang: Failure: isinf (pseudo_zero): Exception "Invalid operation" set Failure: isinf (pseudo_inf): Exception "Invalid operation" set Failure: isinf (pseudo_qnan): Exception "Invalid operation" set Failure: isinf (pseudo_snan): Exception "Invalid operation" set Failure: isinf (pseudo_unnormal): Exception "Invalid operation" set Failure: isinf_downward (pseudo_zero): Exception "Invalid operation" set Failure: isinf_downward (pseudo_inf): Exception "Invalid operation" set Failure: isinf_downward (pseudo_qnan): Exception "Invalid operation" set Failure: isinf_downward (pseudo_snan): Exception "Invalid operation" set Failure: isinf_downward (pseudo_unnormal): Exception "Invalid operation" set Failure: isinf_towardzero (pseudo_zero): Exception "Invalid operation" set Failure: isinf_towardzero (pseudo_inf): Exception "Invalid operation" set Failure: isinf_towardzero (pseudo_qnan): Exception "Invalid operation" set Failure: isinf_towardzero (pseudo_snan): Exception "Invalid operation" set Failure: isinf_towardzero (pseudo_unnormal): Exception "Invalid operation" set Failure: isinf_upward (pseudo_zero): Exception "Invalid operation" set Failure: isinf_upward (pseudo_inf): Exception "Invalid operation" set Failure: isinf_upward (pseudo_qnan): Exception "Invalid operation" set Failure: isinf_upward (pseudo_snan): Exception "Invalid operation" set Failure: isinf_upward (pseudo_unnormal): Exception "Invalid operation" set Checked on x86_64-linux-gnu with gcc-15 and clang-18. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123173 [2] https://github.com/llvm/llvm-project/issues/172651 Reviewed-by: H.J. Lu

x86: Do not use __builtin_fpclassify for _Float64x/long double

2025-12-22T18:55:16Z

Neither gcc [1] nor clang [2] handles pseudo-normal numbers correctly with the __builtin_fpclassify, so disable its usage for _Float64x and long double types. This only affects x86, so add a new header, fp-builtin-denormal.h, that defines whether the architecture requires disabling the optimization through a new glibc define (__FP_BUILTIN_FPCLASSIFY_DENORMAL). It fixes the regression on test-ldouble-fpclassify and test-float64x-fpclassify when built with clang: Failure: fpclassify (pseudo_zero): Exception "Invalid operation" set Failure: fpclassify (pseudo_inf): Exception "Invalid operation" set Failure: fpclassify (pseudo_qnan): Exception "Invalid operation" set Failure: fpclassify (pseudo_snan): Exception "Invalid operation" set Failure: fpclassify (pseudo_unnormal): Exception "Invalid operation" set Failure: fpclassify_downward (pseudo_zero): Exception "Invalid operation" set Failure: fpclassify_downward (pseudo_inf): Exception "Invalid operation" set Failure: fpclassify_downward (pseudo_qnan): Exception "Invalid operation" set Failure: fpclassify_downward (pseudo_snan): Exception "Invalid operation" set Failure: fpclassify_downward (pseudo_unnormal): Exception "Invalid operation" set Failure: fpclassify_towardzero (pseudo_zero): Exception "Invalid operation" set Failure: fpclassify_towardzero (pseudo_inf): Exception "Invalid operation" set Failure: fpclassify_towardzero (pseudo_qnan): Exception "Invalid operation" set Failure: fpclassify_towardzero (pseudo_snan): Exception "Invalid operation" set Failure: fpclassify_towardzero (pseudo_unnormal): Exception "Invalid operation" set Failure: fpclassify_upward (pseudo_zero): Exception "Invalid operation" set Failure: fpclassify_upward (pseudo_inf): Exception "Invalid operation" set Failure: fpclassify_upward (pseudo_qnan): Exception "Invalid operation" set Failure: fpclassify_upward (pseudo_snan): Exception "Invalid operation" set Failure: fpclassify_upward (pseudo_unnormal): Exception "Invalid operation" set Checked on x86_64-linux-gnu with gcc-15 and clang-18. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123161 [2] https://github.com/llvm/llvm-project/issues/172533 Reviewed-by: H.J. Lu

math: Do not use __builtin_isgreater* and __builtin_isless* on clang

2025-12-19T16:23:06Z

clang does not check for unordered numbers with builtins for 128-bit float types (both _Float128 on x86_64 or long double on aarch64) [1]. For instance, the code: #ifdef __x86_64__ typedef __float128 FLOAT128_TYPE; #elif defined (__aarch64__) typedef long double FLOAT128_TYPE; #endif int foo (FLOAT128_TYPE x, FLOAT128_TYPE y) { return __builtin_isgreater (x, y); } Will issue a __gttf2 call instead of a __unordtf2 followed by the comparison. Using the generic implementation fixes multiple issues with math tests, such as: Failure: fmax (0, qNaN): Exception "Invalid operation" set Failure: fmax (0, -qNaN): Exception "Invalid operation" set Failure: fmax (-0, qNaN): Exception "Invalid operation" set Failure: fmax (-0, -qNaN): Exception "Invalid operation" set Failure: fmax (9, qNaN): Exception "Invalid operation" set Failure: fmax (9, -qNaN): Exception "Invalid operation" set Failure: fmax (-9, qNaN): Exception "Invalid operation" set Failure: fmax (-9, -qNaN): Exception "Invalid operation" set It has a small performance overhead due to the extra isunordered (which could be omitted for float and double types). Using _Generic (similar to how __MATH_TG) on a bivariadic function requires a lot of boilerplate macros. [1] https://github.com/llvm/llvm-project/issues/172499 Reviewed-by: H.J. Lu

Define C23 header version macros

2025-11-27T19:32:49Z

C23 defines library macros __STDC_VERSION_

_H__ to indicate that a header has support for new / changed features from C23. Now that all the required library features are implemented in glibc, define these macros. I'm not sure this is sufficiently much of a user-visible feature to be worth a mention in NEWS. Tested for x86_64. There are various optional C23 features we don't yet have, of which I might look at the Annex H ones (floating-point encoding conversion functions and _Float16 functions) next. * Optional time bases TIME_MONOTONIC, TIME_ACTIVE, TIME_THREAD_ACTIVE. See - we need to review / update that patch. (I think patch 2/2, inventing new names for all the nonstandard CLOCK_* supported by the Linux kernel, is rather more dubious.) * Updating conform/ tests for C23. * Defining the rounding mode macro FE_TONEARESTFROMZERO for RISC-V (as far as I know, the only architecture supported by glibc that has hardware support for this rounding mode for binary floating point) and supporting it throughout glibc and its tests (especially the string/numeric conversions in both directions that explicitly handle each possible rounding mode, and various tests that do likewise). * Annex H floating-point encoding conversion functions. (It's not entirely clear which are optional even given support for Annex H; there's some wording applied inconsistently about only being required when non-arithmetic interchange formats are supported; see the comments I raised on the WG14 reflector on 23 Oct 2025.) * _Float16 functions (and other header and testcase support for this type). * Decimal floating-point support. * Fully supporting __int128 and unsigned __int128 as integer types wider than intmax_t, as permitted by C23. Would need doing in coordination with GCC, see GCC bug 113887 for more discussion of what's involved.

Change fromfp functions to return floating types following C23 (bug 28327)

2025-11-13T00:04:21Z

As discussed in bug 28327, C23 changed the fromfp functions to return floating types instead of intmax_t / uintmax_t. (Although the motivation in N2548 was reducing the use of intmax_t in library interfaces, the new version does have the advantage of being able to specify arbitrary integer widths for e.g. assigning the result to a _BitInt, as well as being able to indicate an error case in-band with a NaN return.) As with other such changes from interfaces introduced in TS 18661, implement the new types as a replacement for the old ones, with the old functions remaining as compat symbols but not supported as an API. The test generator used for many of the tests is updated to handle both versions of the functions. Tested for x86_64 and x86, and with build-many-glibcs.py. Also tested tgmath tests for x86_64 with GCC 7 to make sure that the modified case for older compilers in does work. Also tested for powerpc64le to cover the ldbl-128ibm implementation and the other things that are handled differently for that configuration. The new tests fail for ibm128, but all the failures relate to incorrect signs of zero results and turn out to arise from bugs in the underlying roundl, ceill, truncl and floorl implementations that I've reported in bug 33623, rather than indicating any bug in the actual new implementation of the functions for that format. So given fixes for those functions (which shouldn't be hard, and of course should add to the tests for those functions rather than relying only on indirect testing via fromfp), the fromfp tests should start passing for ibm128 as well.

Add C23 long_double_t, _FloatN_t

2025-11-04T17:12:00Z

C23 Annex H adds typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, _t corresponds to the evaluation format for , as specified by FLT_EVAL_METHOD (for which uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so _t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so _t is defined to ). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.

Update copyright dates with scripts/update-copyrights

2025-01-01T19:22:09Z