The pointer alias comparison will be optimized away by the compiler,
and gcc and clang will evaluate differently (clang evaluates as
false, while gcc as true).
clang does not handle pseudo normal numbers, so disable the fpclassify
and isnormal builtin optimization if clang is used. This only affect
x86, so add a new header, fp-builtin-denormal.h, which defines whether
the architecture required to disable the optimization through a new
glibc define (__FP_BUILTIN_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
clang generates internal calls for some _chk symbol, so add internal
aliases for them, and stub some with rtld-stubbed-symbols to avoid
ld.so linker issues.
configure: remove overly restrictive check for clang
The clang support is still experimental and not all testcase build
or run correctly. Only clang 18 and onwards is supported and only
for x86_64-linux-gnu and aarch64-linux-gnu.
clang generates internal calls for some _chk symbol, so add internal
aliases for them, and stub some with rtld-stubbed-symbols to avoid
ld.so linker issues.
Recent lld version default to --no-undefined-version, which triggers
errors when building multiple libraries. For ld.so on x86_64 it fails
with:
ld.lld: error: version script assignment of 'GLIBC_2.4' to symbol '__stack_chk_guard' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_PRIVATE' to symbol '__nptl_set_robust_list_avail' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_PRIVATE' to symbol '__pointer_chk_guard' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_PRIVATE' to symbol '_dl_starting_up' failed: symbol not defined
While for libc.so:
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_clearerr' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_fgetc' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_fileno' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_freopen' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_fscanf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_fseek' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_peekc_unlocked' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_stderr_' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_stdin_' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_stdout_' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_pclose' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_perror' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_rewind' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_scanf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_setbuf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_setlinebuf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_wdefault_setbuf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '_IO_wfile_setbuf' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '__ctype32_tolower' failed: symbol not defined
ld.lld: error: version script assignment of 'GLIBC_2.17' to symbol '__ctype32_toupper' failed: symbol not defined
ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
The version script is created with multiple missing symbols to simplify
the build for multiple ABIs, each of which may have different symbols.
For instance, __stack_chk_guard is defined by default. This avoids
requiring each ABI to add this symbol to its version script, depending
on the stack protector ABI it uses.
The libc.so warnings do show unused symbols being defined (like
_IO_clearerr), which might trigger potential errors depending on how
symbols are exported. However, since we already have ABI checks for
missing and extra symbols, the linker's extra checks are not really
necessary.
The --no-undefined-version is the default for ld.bfd.
Supress unused command arguments warning with clang
clang 20 issues an warning for the unused '-c' argument used to create
errlist-data-aux-shared.S, errlist-data-aux.S, siglist-aux-shared.S,
and siglist-aux.S. Filter out the '-c' from the $(compile-command.c).
The clang default to warning for missing fall-through and it does
not support all comment-like annotation that gcc does. Use C23
[[fallthrough]] annotation instead.
proper attribute instead.
clang supports it from version 19 and onwards, but it should be gated
as an option to assembler (either with -Wa or -Xassembler). Add a
test for -Wa as well if -msse2avx fully supported by the compiler.
Clang warns that another_external_impl always resolves to __internal_impl,
even if external_impl is a weak reference. Using the internal symbol for
both aliases resolves this warning.
This issue also occurs with certain libc_hidden_def usage:
int __internal_impl (...) {}
weak_alias (__internal_impl, __internal_alias)
libc_hidden_weak (__internal_alias)
In this case, using a strong_alias is sufficient to avoid the warning
(since the alias is internal, there is no need to use a weak alias).
Clang warns that the internal external_alias will always resolve to
__GI___internal_impl eve if a weak definition to __GI_internal_impl is
overriden. For this case, a new macro named static_weak_alias is used
to create a strong alias for SHARED, or a weak_alias otherwise.
With these changes, there is no need to check and enable the
-Wno-ignored-attributes suppression when using clang.
argp: Expand argp_usage, _option_is_short, and _option_is_end
The argp code uses macro redefinitions to avoid duplicating static inline
implementations for argp_usage, _option_is_short, and _option_is_end.
However, this causes build issues with clang, as some function prototypes
are redefined to add the hidden attribute with libc_hidden_proto.
To avoid extensive changes to internal headers, just expand the function
implementations and avoid the macro redefine tricks.
compiler may redirect truncf calls to __truncf, instead of inlining it
(for instance, clang). The USE_TRUNCF_BUILTIN is 1 to indicate that
truncf should be inlined. In this case, we don't want the truncf
redirection:
1. For each math function which may be inlined, we define
With this change If USE_TRUNCF_BUILTIN is 0, we get
float (truncf) (float) asm ("__truncf");
truncf will be redirected to __truncf.
And for USE_TRUNCF_BUILTIN 1, we get:
float (inline_truncf) (float) asm ("__truncf");
In both cases either truncf will be inlined or the internal alias
(__truncf) will be called.
It is not required for all math-use-builtin symbol, only the one
defined in math.h. It also allows to remove all the math-use-builtin
inclusion, since it is now implicitly included by math.h.
For MIPS, some math-use-builtin headers include sysdep.h and this
in turn includes a lot of extra headers that do not allow ldbl-128
code to override alias definition (math.h will include
some stdlib.h definition). The math-use-builtin only requires
the __mips_isa_rev, so move the defintion to sgidefs.h.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To enable “longlong.h” removal, the umul_ppmm is moved to a gmp-arch.h.
The generic implementation now uses a static inline, which provides
better type checking than the GNU extension to cast the asm constraint
(and it works better with clang).
Most of the architecture uses the generic implementation, which is
expanded from a macro, except for alpha, arm, hppa, x86, m68k, mips,
powerpc, and sparc. I kept only x86 optimization, where there is no
easy way to emit mul{q}. For the rest, the compiler generates good
enough code.
To enable “longlong.h” removal, add_ssaaaa and sub_ssaaaa are moved to
gmp-arch.h. The generic implementation now uses a static inline. This
provides better type checking than the GNU extension, which casts the
asm constraint. It also works better with clang.
Most architectures use the generic implementation. This is expanded
from a macro. Exceptions are arc, arm, hppa, x86, m68k, powerpc, and
sparc. I kept only the x86 optimization, as there is no easy way to
emit add{q}. For all others, the compiler generates good enough code.
The strongly typed implementation required some changes. I adjusted
_FP_W_TYPE, _FP_WS_TYPE, and _FP_I_TYPE to use the same type as
mp_limb_t on aarch64, powerpc64le, x86_64, and riscv64. This basically
means using “long” instead of “long long.”
To enable “longlong.h” removal, the udiv_qrnnd is moved to a gmp-arch.h
file. It allows each architecture to implement its own arch-specific
optimizations. The generic implementation now uses a static inline,
which provides better type checking than the GNU extension to cast the
asm constraint (and it works better with clang).
Most of the architecture uses the generic implementation, which is
expanded from a macro, except for alpha, x86, m68k, sh, and sparc.
I kept that alpha, which uses out-of-the-line implementations and x86,
where there is no easy way to use the div{q} instruction from C code.
For the rest, the compiler generates good enough code.
The hppa also provides arch-specific implementations, but they are not
routed in “longlong.h” and thus never used.
The count_leading_zeros is not used anymore, so there is no need to
provide the table for possible usage. The hppa already provides
the compat symbol on libgcc-compat.c.
The main change is to proper support clang by using builtins. It
fixes a sprof build issue, where previous version uses the generic
code path when building with clang:
sprof.c:682:8: error: result of comparison of constant 288230376151711743 with expression of type 'Elf64_Half' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
682 | if (INT_MULTIPLY_WRAPV (ehdr2.e_shnum, sizeof (ElfW(Shdr)), &size))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/intprops.h:415:34: note: expanded from macro 'INT_MULTIPLY_WRAPV'
415 | _GL_INT_OP_WRAPV (a, b, r, *, _GL_INT_MULTIPLY_RANGE_OVERFLOW)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/intprops.h:504:45: note: expanded from macro '_GL_INT_OP_WRAPV'
504 | : _GL_INT_OP_WRAPV_LONGISH(a, b, r, op, overflow))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
../include/intprops.h:511:41: note: expanded from macro '_GL_INT_OP_WRAPV_LONGISH'
511 | : _GL_INT_OP_CALC (a, b, r, op, overflow, unsigned long int, \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
512 | unsigned long int, 0, ULONG_MAX)) \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/intprops.h:533:4: note: expanded from macro '_GL_INT_OP_CALC'
533 | (overflow (a, b, tmin, tmax) \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/intprops.h:608:22: note: expanded from macro '_GL_INT_MULTIPLY_RANGE_OVERFLOW'
608 | : (tmax) / (b) < (a)))
| ~~~~~~~~~~~~ ^ ~~~
1 error generated.
The current implementation precision shows the following accuracy, on
three ranges ([-DBL_MAX,5], [-5,5], [5,DBL_MAX]) with 10e9 uniform
randomly generated numbers for each range (first column is the
accuracy in ULP, with '0' being correctly rounded, second is the
number of samples with the corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The current implementation precision shows the following accuracy, on
three rangeis ([-DBL_MIN, -4.2], [-4.2, 4.2], [4.2, DBL_MAX]) with
10e9 uniform randomly generated numbers for each range (first column
is the accuracy in ULP, with '0' being correctly rounded, second is the
number of samples with the corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The current implementation precision shows the following accuracy, on
one range ([-20,20]) with 10e9 uniform randomly generated numbers for
each range (first column is the accuracy in ULP, with '0' being
correctly rounded, second is the number of samples with the
corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The current implementation precision shows the following accuracy, on
one range ([-1,1]) with 10e9 uniform randomly generated numbers for
each range (first column is the accuracy in ULP, with '0' being
correctly rounded, second is the number of samples with the
corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The internal data definitions are moved to s_atanh_data.c.
It helps on ABIs that build the implementation multiple times for
ifunc optimizations, like x86_64.
The current implementation precision shows the following accuracy, on
one range ([-1,1]) with 10e9 uniform randomly generated numbers for
each range (first column is the accuracy in ULP, with '0' being
correctly rounded, second is the number of samples with the
corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The current implementation precision shows the following accuracy, on
tthree different ranges ([-DBL_MAX, -10], [-10,10], and [10, DBL_MAX))
with 10e9 uniform randomly generated numbers for each range (first
column is the accuracy in ULP, with '0' being correctly rounded, second
is the number of samples with the corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
The current implementation precision shows the following accuracy, on
two different ranges ([1,21) and [21, DBL_MAX)) with 10e9 uniform
randomly generated numbers (first column is the accuracy in ULP, with
'0' being correctly rounded, second is the number of samples with the
corresponding precision):
The CORE-MATH implementation is correctly rounded for any rounding mode.
The code was adapted to glibc style and to use the definition of
math_config.h (to handle errno, overflow, and underflow).
Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
litenglong [Fri, 17 Oct 2025 01:45:41 +0000 (09:45 +0800)]
x86: Disable AVX Fast Unaligned Load on Hygon 1/2/3
- Performance testing revealed significant memcpy performance degradation
when bit_arch_AVX_Fast_Unaligned_Load is enabled on Hygon 3.
- Hygon confirmed AVX performance issues in certain memory functions.
- Glibc benchmarks show SSE outperforms AVX for
memcpy/memmove/memset/strcmp/strcpy/strlen and so on.
- Hardware differences primarily in floating-point operations don't justify
AVX usage for memory operations.
Reviewed-by: gaoxiang <gaoxiang@kylinos.cn> Signed-off-by: litenglong <litenglong@kylinos.cn> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Dev Jain [Fri, 24 Oct 2025 16:52:21 +0000 (16:52 +0000)]
malloc: fix large tcache code to check for exact size match
The tcache is used for allocation only if an exact match is found. In the
large tcache code added in commit cbfd7988107b, we currently extract a
chunk of size greater than or equal to the size we need, but don't check
strict equality. This patch fixes that behaviour.
Paul Zimmermann [Tue, 14 Oct 2025 07:58:20 +0000 (09:58 +0200)]
various fixes detected with -Wdouble-promotion
Changes with respect to v1:
- added comment in e_j1f.c to explain the use of float is enough Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
H.J. Lu [Tue, 21 Oct 2025 23:29:03 +0000 (07:29 +0800)]
plot_strings.py: Replace np.complex with complex
Replace np.complex with complex to fix numpy error:
AttributeError: module 'numpy' has no attribute 'complex'.
`np.complex` was a deprecated alias for the builtin `complex`. To avoid this error in existing code, use `complex` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use `np.complex128` here.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
DJ Delorie [Thu, 28 Aug 2025 20:30:30 +0000 (16:30 -0400)]
malloc: avoid need for tcache == NULL checks
Avoid needing to check for tcache == NULL by initializing it
to a dummy read-only tcache structure. This dummy is all zeros,
so logically it is both full (when you want to put) and empty (when
you want to get). Also, there are two dummies, one used for
"not yet initialized" and one for "tunables say we shouldn't have
a tcache".
The net result is twofold:
1. Checks for tcache == NULL may be removed from the fast path.
Whether this makes the fast path faster when tcache is
disabled is TBD, but the normal case is tcache enabled.
2. no memory for tcache is allocated if tunables disable caching.
Simplify powl computation for small integral y [BZ #33411]
The powl implementation for x86_64 ends up multiplying X once more than
necessary and then throwing away that result. This results in an
overflow flag being set in cases where there is no overflow.
Simplify the relevant portion by special casing the -3 to 3 range and
simply multiplying repetitively.
rtime.c:96:36: error: variable 'thetime' is uninitialized when passed as a const pointer argument here
[-Werror,-Wuninitialized-const-pointer]
96 | res = __sendto (s, (char *) &thetime, sizeof (thetime), 0,
| ^~~~~~~
For SOCK_DGRAM the sendto sends an uninitialized value.
To use the fabs function to the used type, instead of the double
variant. it fixes a build issue with clang:
./s_compoundn_template.c:64:14: error: absolute value function 'fabs' given an argument of type 'const long double' but has parameter of type 'double' which may cause truncation of value [-Werror,-Wabsolute-value]
64 | FLOAT pd = fabs (*(const FLOAT *) p);
| ^
./s_compoundn_template.c:64:14: note: use function 'fabsl' instead
64 | FLOAT pd = fabs (*(const FLOAT *) p);
| ^~~~
| fabsl
Recent clang version optimizes some loops contructions to strlen [1],
which might generate function calls when self-relocation is not
already done (on tunable parsing). Use an out-of-line function
with __attribute_optimization_barrier__ to avoid this.
And although NAME_IFUNC is and alias for NAME, clang still emits
an 'unused function 'name_ifunc' [-Werror,-Wunused-function]'
warning. The static is used to avoid name pollution on static
linkage.
stdio: Fix -Wtautological-constant-out-of-range-compare on clang
clang emits an error while building vfprintf-internal for default
case:
error: result of comparison of constant 255 with expression of type
'char' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
if (spec <= UCHAR_MAX
The test is indeed not required for default non-wide build.
On ABIs with defined 'char' was unsigned type, clang fails to build
support_process_state.c with:
support_process_state.c:70:21: error: result of comparison of constant -1 with expression of type 'char' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
70 | if (cur_state == -1)
| ~~~~~~~~~ ^ ~~
1 error generated.
math: Suppress clang -Wincompatible-library-redeclaration on s_llround
Clang issues:
../sysdeps/ieee754/dbl-64/s_llround.c:83:30: error: incompatible
redeclaration of library function 'lround'
[-Werror,-Wincompatible-library-redeclaration]
libm_alias_double (__lround, lround)
^
../sysdeps/ieee754/dbl-64/s_llround.c:83:30: note: 'lround' is a builtin
with type 'long (double)'
../sysdeps/ieee754/dbl-64/e_lgamma_r.c:234:29: error: absolute value function 'fabsf'
given an argument of type 'double' but has parameter of type 'float' which may cause \
truncation of value [-Werror,-Wabsolute-value]
It should not matter because the value is 0.0, but using fabs is
simpler than adding a warning suppresion.
math: Suppress clang -Wabsolute-value warning on math_check_force_underflow
clang warns:
../sysdeps/x86/fpu/powl_helper.c:233:3: error: absolute value function
'__builtin_fabsf' given an argument of type 'typeof (res)' (aka 'long
double') but has parameter of type 'float' which may cause truncation of
value [-Werror,-Wabsolute-value]
math_check_force_underflow (res);
^
./math-underflow.h:45:11: note: expanded from macro
'math_check_force_underflow'
if (fabs_tg (force_underflow_tmp) \
^
./math-underflow.h:27:20: note: expanded from macro 'fabs_tg'
#define fabs_tg(x) __MATH_TG ((x), (__typeof (x)) __builtin_fabs, (x))
^
../math/math.h:899:16: note: expanded from macro '__MATH_TG'
float: FUNC ## f ARGS, \
^
<scratch space>:73:1: note: expanded from here
__builtin_fabsf
^
It simplifies the code a bit and avoid the clang warning:
./config.h:12:2: error: #include_next in file found relative to primary
source file or found by absolute path; will search from start of include
path [-Werror,-Winclude-next-absolute-path]
#include_next <config.h>
^
sunrpc: Suppress clang -Wgnu-variable-sized-type-not-at-end warning on struct cmessage
clang issues:
svc_unix.c:318:18: error: field 'cmsg' with variable sized type 'struct cmsghdr' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
318 | struct cmsghdr cmsg;
| ^
The __msgread explicitly expects that 'struct ucred' is after the 'cmsg',
so suppress the warning.
clang does not allow to redefine attributes after function declaration.
Although it work for external usage, its breaks the build for internal
symbol that glibc provides as optimization (for instance bsearch
with stdlib-bsearch.h or __cmsg_nxthdr).
Disable such optimization for clang while building glibc.
Dev Jain [Fri, 17 Oct 2025 14:18:43 +0000 (19:48 +0530)]
malloc: Do not call madvise if heap's oldsize >= THP size
Linux handles virtual memory in Virtual Memory Areas (VMAs). The
madvise(MADV_HUGEPAGE) call works on a VMA granularity, which sets the
VM_HUGEPAGE flag on the VMA. This flag is invariant of the mprotect()
syscall which is used in growing the secondary heaps. Therefore, we
need to call madvise() only when we are sure that VM_HUGEPAGE was not
previously set, which is only in the case when h->size < mp_.thp_pagesize.
Luc Michel [Fri, 17 Oct 2025 09:27:12 +0000 (11:27 +0200)]
microblaze: fix __syscall_cancel_arch (BZ 33547)
The __syscall_cancel_arch function has an epilogue that does not match
the prologue. The stack is not used and the return address still lies in
r15 when reaching the epilogue. Fix the epilogue by simply returning
from the function.
programs/ld-collate.c:1824:55: error: implicit conversion from 'unsigned
long' to 'unsigned int' changes value from 18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion]
collate->undefined.used_in_level = need_undefined ? ~0ul : 0;
~ ^~~~
GCC enables it by default, clang in the other hand sets -fno-trapping-math.
This is required to fix some math and stdlib tests that explicit raises
floating point exceptions:
math/test-double-canonicalize.out
testing double (without inline functions)
Failure: canonicalize (max_value): Exception "Overflow" set
Failure: canonicalize (max_value): Exception "Inexact" set
Failure: canonicalize (-max_value): Exception "Overflow" set
Failure: canonicalize (-max_value): Exception "Inexact" set
Failure: canonicalize_downward (max_value): Exception "Overflow" set
Failure: canonicalize_downward (max_value): Exception "Inexact" set
Failure: canonicalize_downward (-max_value): Exception "Overflow" set
Failure: canonicalize_downward (-max_value): Exception "Inexact" set
Failure: canonicalize_towardzero (max_value): Exception "Overflow" set
Failure: canonicalize_towardzero (max_value): Exception "Inexact" set
Failure: canonicalize_towardzero (-max_value): Exception "Overflow" set
Failure: canonicalize_towardzero (-max_value): Exception "Inexact" set
Failure: canonicalize_upward (max_value): Exception "Overflow" set
Failure: canonicalize_upward (max_value): Exception "Inexact" set
Failure: canonicalize_upward (-max_value): Exception "Overflow" set
Failure: canonicalize_upward (-max_value): Exception "Inexact" set
test-float-catanh.out
testing float (without inline functions)
Failure: Real part of: catanh (-0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (-0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh (-0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (-0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh (-0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (-0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh (0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh (0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh (0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (-0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_downward (0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (-0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_towardzero (0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (-0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0x1.000002p+0 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0x1.000002p+0 - 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0x1.000002p+0 + 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0x1.000002p+0 + 0x8p-152 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0xf.fffffp-4 - 0x4p-128 i): Exception "Underflow" set
Failure: Real part of: catanh_upward (0xf.fffffp-4 + 0x4p-128 i): Exception "Underflow" set
projects / thirdparty / glibc.git / log
