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.
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.
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.
H.J. Lu [Mon, 15 Sep 2025 18:24:22 +0000 (11:24 -0700)]
Build programs in $(others-noinstall) like tests
Programs in $(others-noinstall) are internal to glibc build and they
aren't installed. They should be treated like programs in $(others),
but linked like tests so that --enable-hardcoded-path-in-tests also
applies to them.
Also replace run-via-rtld-prefix with test-via-rtld-prefix when running
container tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com>
Osama Abdelkader [Tue, 28 Oct 2025 20:58:35 +0000 (23:58 +0300)]
Fix incorrect setrlimit return value checks in tests
The setrlimit(2) function returns 0 on success and -1 on error, but
several test files were incorrectly checking for a return value of 1
to detect errors. This means the error checks would never trigger,
causing tests to continue silently even when setrlimit() failed.
This commit fixes the error checks in five files to correctly test
for -1, matching both the documented behavior and the pattern used
correctly in other parts of the codebase.
Joseph Myers [Tue, 28 Oct 2025 12:15:02 +0000 (12:15 +0000)]
Rename uimaxabs to umaxabs (bug 33325)
The C2y function uimaxabs has been renamed to umaxabs. Implement this
change in glibc, keeping a compat symbol under the old name, copying
the test to test the new name and changing the old test to test the
compat symbol. Jakub has done the corresponding change to the
built-in function in GCC.
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
The constant should be used with c_cc, which for all supported ABIs
is defined as unsigned char. By using it as literar char constant,
clang triggers an error when compared with signal literal on ABIs that
define 'char' as unsigned.
On aarch64, clang shows:
../sysdeps/posix/fpathconf.c:118:21: error: right side of operator
converted from negative value to unsigned: -1 to 18446744073709551615
[-Werror]
#if _POSIX_VDISABLE == -1
~~~~~~~~~~~~~~~ ^ ~~
Joseph Myers [Mon, 20 Oct 2025 12:44:40 +0000 (12:44 +0000)]
Make <inttypes.h> printf macros narrow arguments (bug 31470)
A late change in C23, the resolution to CD2 comment GB-108, specified
that <inttypes.h> macros such as PRId8 expand to formats such that,
when an argument is passed in the promoted type that isn't
representable in the original type such as int8_t corresponding to the
format, it gets converted to that type before printing. (Previously,
the proper handling of such arguments was unclear; the case of direct
use of formats such as %hhd was clarified earlier in C23 development,
and had been fixed in glibc in 2006.) Implement the change to use
formats such as "hhd" for the affected macros, with associated tests.
Wilco Dijkstra [Thu, 2 Oct 2025 15:53:31 +0000 (15:53 +0000)]
malloc: Cleanup _int_memalign
Cleanup _int_memalign. Simplify the logic. Add a seperate check
for mmap. Only release the tail chunk if it is at least MINSIZE.
Use the new mmap abstractions.
Joseph Myers [Fri, 17 Oct 2025 16:56:59 +0000 (16:56 +0000)]
Implement C23 memalignment
Add the C23 memalignment function (query the alignment of a pointer)
to glibc.
Given how simple this operation is, it would make sense for compilers
to inline calls to this function, but I'm treating that as a compiler
matter (compilers should add it as a built-in function) rather than
adding an inline version to glibc headers (although such an inline
version would be reasonable as well). I've filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122117 for this feature
in GCC.
This commit adds tests for the following use cases relevant to handing of
the SME state:
- fork() and vfork()
- clone() and clone3()
- signal handler
While most cases are trivial, the case of clone3() is more complicated since
the clone3() symbol is not public in Glibc.
To avoid having to check all possible ways clone3() may be called via other
public functions (e.g. vfork() or pthread_create()), we put together a test
that links directly with clone3.o. All the existing functions that have calls
to clone3() may not actually use it, in which case the outcome of such tests
would be unexpected. Having a direct call to the clone3() symbol in the test
allows to check precisely what we need to test: that the __arm_za_disable()
function is indeed called and has the desired effect.
Linking to clone3.o also requires linking to __arm_za_disable.o that in
turn requires the _dl_hwcap2 hidden symbol which to provide in the test
and initialise it before using.
aarch64: clear ZA state of SME before clone and clone3 syscalls
This change adds a call to the __arm_za_disable() function immediately
before the SVC instruction inside clone() and clone3() wrappers. It also
adds a macro for inline clone() used in fork() and adds the same call to
the vfork implementation. This sets the ZA state of SME to "off" on return
from these functions (for both the child and the parent).
The __arm_za_disable() function is described in [1] (8.1.3). Note that
the internal Glibc name for this function is __libc_arm_za_disable().
When this change was originally proposed [2,3], it generated a long
discussion where several questions and concerns were raised. Here we
will address these concerns and explain why this change is useful and,
in fact, necessary.
In a nutshell, a C library that conforms to the AAPCS64 spec [1] (pertinent
to this change, mainly, the chapters 6.2 and 6.6), should have a call to the
__arm_za_disable() function in clone() and clone3() wrappers. The following
explains in detail why this is the case.
When we consider using the __arm_za_disable() function inside the clone()
and clone3() libc wrappers, we talk about the C library subroutines clone()
and clone3() rather than the syscalls with similar names. In the current
version of Glibc, clone() is public and clone3() is private, but it being
private is not pertinent to this discussion.
We will begin with stating that this change is NOT a bug fix for something
in the kernel. The requirement to call __arm_za_disable() does NOT come from
the kernel. It also is NOT needed to satisfy a contract between the kernel
and userspace. This is why it is not for the kernel documentation to describe
this requirement. This requirement is instead needed to satisfy a pure userspace
scheme outlined in [1] and to make sure that software that uses Glibc (or any
other C library that has correct handling of SME states (see below)) conforms
to [1] without having to unnecessarily become SME-aware thus losing portability.
To recap (see [1] (6.2)), SME extension defines SME state which is part of
processor state. Part of this SME state is ZA state that is necessary to
manage ZA storage register in the context of the ZA lazy saving scheme [1]
(6.6). This scheme exists because it would be challenging to handle ZA
storage of SME in either callee-saved or caller-saved manner.
There are 3 kinds of ZA state that are defined in terms of the PSTATE.ZA
bit and the TPIDR2_EL0 register (see [1] (6.6.3)):
As [1] (6.7.2) outlines, every subroutine has exactly one SME-interface
depending on the permitted ZA-states on entry and on normal return from
a call to this subroutine. Callers of a subroutine must know and respect
the ZA-interface of the subroutines they are using. Using a subroutine
in a way that is not permitted by its ZA-interface is undefined behaviour.
In particular, clone() and clone3() (the C library functions) have the
ZA-private interface. This means that the permitted ZA-states on entry
are "off" and "dormant" and that the permitted states on return are "off"
or "dormant" (but if and only if it was "dormant" on entry).
This means that both functions in question should correctly handle both
"off" and "dormant" ZA-states on entry. The conforming states on return
are "off" and "dormant" (if inbound state was already "dormant").
This change ensures that the ZA-state on return is always "off". Note,
that, in the context of clone() and clone3(), "on return" means a point
when execution resumes at certain address after transferring from clone()
or clone3(). For the caller (we may refer to it as "parent") this is the
return address in the link register where the RET instruction jumps. For
the "child", this is the target branch address.
So, the "off" state on return is permitted and conformant. Why can't we
retain the "dormant" state? In theory, we can, but we shouldn't, here is
why.
Every subroutine with a private-ZA interface, including clone() and clone3(),
must comply with the lazy saving scheme [1] (6.7.2). This puts additional
responsibility on a subroutine if ZA-state on return is "dormant" because
this state has special meaning. The "caller" (that is the place in code
where execution is transferred to, so this include both "parent" and "child")
may check the ZA-state and use it as per the spec of the "dormant" state that
is outlined in [1] (6.6.6 and 6.6.7).
Conforming to this would require more code inside of clone() and clone3()
which hardly is desirable.
For the return to "parent" this could be achieved in theory, but given that
neither clone() nor clone3() are supposed to be used in the middle of an
SME operation, if wouldn't be useful. For the "return" to "child" this
would be particularly difficult to achieve given the complexity of these
functions and their interfaces. Most importantly, it would be illegal
and somewhat meaningless to allow a "child" to start execution in the
"dormant" ZA-state because the very essence of the "dormant" state implies
that there is a place to return and that there is some outer context that
we are allowed to interact with.
To sum up, calling __arm_za_disable() to ensure the "off" ZA-state when the
execution resumes after a call to clone() or clone3() is correct and also
the most simple way to conform to [1].
Can there be situations when we can avoid calling __arm_za_disable()?
Calling __arm_za_disable() implies certain (sufficiently small) overhead,
so one might rightly ponder avoiding making a call to this function when
we can afford not to. The most trivial cases like this (e.g. when the
calling thread doesn't have access to SME or to the TPIDR2_EL0 register)
are already handled by this function (see [1] (8.1.3 and 8.1.2)). Reasoning
about other possible use cases would require making code inside clone() and
clone3() more complicated and it would defeat the point of trying to make
an optimisation of not calling __arm_za_disable().
Why can't the kernel do this instead?
The handling of SME state by the kernel is described in [4]. In short,
kernel must not impose a specific ZA-interface onto a userspace function.
Interaction with the kernel happens (among other thing) via system calls.
In Glibc many of the system calls (notably, including SYS_clone and
SYS_clone3) are used via wrappers, and the kernel has no control of them
and, moreover, it cannot dictate how these wrappers should behave because
it is simply outside of the kernel's remit.
However, in certain cases, the kernel may ensure that a "child" doesn't
start in an incorrect state. This is what is done by the recent change
included in 6.16 kernel [5]. This is not enough to ensure that code that
uses clone() and clone3() function conforms to [1] when it runs on a
system that provides SME, hence this change.
Collin Funk [Sun, 12 Oct 2025 02:01:05 +0000 (19:01 -0700)]
posix: Avoid a stack overflow when glob is given many slashes [BZ #30635]
* posix/glob.c (__glob): Strip trailing slashes before the recursive
call, so it is not called for every slash in the pattern.
* posix/tst-glob-bz30635.c: Add two test cases that would previously
segmentation fault. The first test has many trailing slashes and the
second has many slashes following a wildcard character.
* posix/Makefile (tests): Add the new test.
Arjun Shankar [Mon, 13 Oct 2025 13:51:09 +0000 (15:51 +0200)]
string: Add tests for unique strerror and strsignal strings
strerror, strsignal, and their variants should return unique strings for
each known (and, depending on the function, unknown) error/signal. Add
tests to verify this for strerror, strerror_r (GNU and XSI compliant
variants), and strerror_l (for the C locale), strerrordesc_np,
strsignal, sigabbrev_np, and sigdescr_np.
Uros Bizjak [Thu, 9 Oct 2025 18:44:59 +0000 (20:44 +0200)]
i386: Use __seg_gs qualifiers in PTR_{MANGLE,DEMANGLE}() macros
Use __seg_gs named address space qualifiers in PTR_MANGLE() and
PTR_DEMANGLE() macros to access the pointer_guard field in the TCB.
This change allows the compiler to eliminate redundant reads of
the variable, reducing the number of reads from 105 to 94 and
decreasing the text size of the library by 280 bytes.
While at it, fix a few trivial whitespace issues as well
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Uros Bizjak [Thu, 9 Oct 2025 18:44:17 +0000 (20:44 +0200)]
x86_64: Use __seg_fs qualifiers in PTR_{MANGLE,DEMANGLE}() macros
Use __seg_fs named address space qualifiers in PTR_MANGLE() and
PTR_DEMANGLE() macros to access the pointer_guard field in the TCB.
This change allows the compiler to eliminate redundant reads of
the variable, reducing the number of reads from 98 to 89 and
decreasing the text size of the library by 512 bytes.
While at it, fix a few trivial whitespace issues as well.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Sergey Kolosov [Fri, 10 Oct 2025 15:15:27 +0000 (17:15 +0200)]
resolv: Add tests for getaddrinfo returning EAI_AGAIN [BZ #16849]
This patch adds two tests that verify correct behavior of getaddrinfo
when DNS resolution fails with a temporary error. Both tests ensure
that getaddrinfo returns EAI_AGAIN in cases where no valid address can
be resolved due to network or resolver failure.
* tst-getaddrinfo-eai-again.c
Runs inside the glibc test-container without any DNS server
configured. The test performs queries using AF_INET, AF_INET6,
and AF_UNSPEC and verifies that getaddrinfo returns EAI_AGAIN
when resolution fails.
* tst-getaddrinfo-eai-again-timeout.c
Runs outside of the container but uses the resolv_test framework
to simulate network failures. The test covers two failure modes:
- No response from the server (resolv_response_drop)
- Zero-length reply from the server
In both cases, getaddrinfo is expected to return EAI_AGAIN.
projects / thirdparty / glibc.git / log
