When the compiler selects IEEE-128 long double ABI(-mabi=ieeelongdouble),
calls to printf, fprintf, sprintf and snprintf are redirected to the
__printfieee128, __fprintfieee128, __sprintfieee128 and __snprintfieee128
symbols respectively. This causes "break printf" (and others) in
GDB to fail because the original symbol names do not exist as global
symbols in libc.so.6.
Fix this by adding local symbol aliases in the ieee128 compatibility
files so that the original symbol names are present in the symbol table
again. This restores the expected GDB behavior ("break printf" works)
without requiring dynamic symbols or versioned compatibility symbols.
Suggested-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The __USE_EXTERN_INLINES is gated __OPTIMIZE_SIZE__, so also gated
the alias required using the same logic.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The 13cfd77bf5 change broke the b5d88fa6c3 fix by removing the symbol
to __symbol redirections. Although it works for -O2 with both gcc
and clang, with -Os without the redirection, the libcall might still
be issued.
This patch reinstates the b5d88fa6c3 fix, with a modification that
allows each ifunc variant to control which trunc to issue. This is
required for clang, which defines HAVE_X86_INLINE_TRUNC to 1 (meaning
that trunc will always be lowered to the instruction on -Os).
Checked on x86_64-linux-gnu with -O2 and -Os with gcc-15 and clang-18.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The CORE-MATH c423b9a3 commit made atanh to use a slight different
muldd_acc and polydd (which uses muldd_acc internally) compared
to previous version.
The new tests were suggested by Paul Zimmermann (although I did
not see any regression).
Checked on x86_64-linux-gnu, x86_64-linux-gnu-v3, aarch64-linux-gnu,
and i686-linux-gnu.
Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
The CORE-MATH c423b9a3 commit made atanh to use a slight different
muldd_acc, mulddd, and polydd (which uses muldd_acc internally)
compare to asinh and acosh.
The new tests were suggested by Paul Zimmermann (although I did
not see any regression).
Checked on x86_64-linux-gnu, x86_64-linux-gnu-v3, aarch64-linux-gnu,
and i686-linux-gnu.
Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
When either program path of module name is empty, don't print an
empty string followed by a colon.
Also fix-up test for a static BTI binary to check error message
for this case.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
__sigreturn2 uses _hurd_sigstate_unlock after restoring the interrupted
xmm values, we thus need it not to touch xmm. It makes sense to inline
sigstate_is_global_rcv _hurd_sigstate_lock/unlock anyway. unlock calls
gsync_wake, so we need to avoid xmm there as well.
If the kernel supports the COPY_FILE_RANGE_64 FUSE interface, we can
safely tests the large size values.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Tested-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
On Linux >= 6.18, the kernel submits the new COPY_FILE_RANGE_64
operation to the fuse implementation for large files. There is a
fall-back routine to COPY_FILE_RANGE but it's only used if
COPY_FILE_RANGE_64 returns ENOSYS.
So, return ENOSYS instead of EIO for "unsupported" operations in order
to make the kernel do the correct thing for this case and maybe in case
that a new operation is added into the kernel fuse interface in the
future.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
All checks related to the PT_GNU_PROPERTY bits would be skipped
if the binary had no PT_GNU_PROPERTY note at all. This meant that
enforcing an abort when some bits are not present was not possible.
Fixes BZ 33713
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* manual/math.texi (Mathematical Constants):
Don’t say that long double is “the same as” double, as the
types remain distinct (problem reported by Keith Thompson).
Also, don’t imply that float is the “narrowest”, as floating
point types don’t have widths in Standard C. Instead, talk
about precision and exponent range.
This is needed for the next patch which updates copyright dates.
* elf/sprof.c:
* sysdeps/unix/sysv/linux/tst-pidfd_getinfo.c:
Remove trailing white space.
* misc/tst-atomic.c: Remove trailing empty line.
Fix regression in commit 7447efa962
("malloc: remove fastbin code from malloc_info") where the closing
`sizes` tag had a typo, missing the '/'.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
clang issues:
malloc.c:1909:8: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
1909 | if (!DEFAULT_THP_PAGESIZE || mp_.thp_mode != malloc_thp_mode_not_supported)
| ^
../sysdeps/unix/sysv/linux/aarch64/malloc-hugepages.h:19:35: note: expanded from macro 'DEFAULT_THP_PAGESIZE'
19 | #define DEFAULT_THP_PAGESIZE (1UL << 21)
Checked on aarch64-linux-gnu.
The intention of the call "xmalloc(256 * 1024)" in tst-decorate-maps is
to force malloc() to fall back to using mmap() since such an amount
won't be available from the main heap.
Post 321e1fc73f, on aarch64, the heap gets extended by default by at
least 2MB, thus the aforementioned call may get satisfied on the main
heap itself. Thus, increase the amount of memory requested to force the
mmap() path again.
Checked on aarch64-linux-gnu.
The pointer alias comparison will be optimized away by the compiler,
so use an indirection point to prevent it (similar to
malloc/tst-malloc-aux.h).
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
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 <hjl.tools@gmail.com>
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 <hjl.tools@gmail.com>
Add a test which verifies that getaddrinfo does not fail if one of A/AAAA
responses is NOERROR/NODATA reply with recursion unavailable and the other
response provides an address.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
This patch adds an RVV-optimized implementation of memset for RISC-V and
enables it for both multiarch (IFUNC) and non-multiarch builds.
The implementation integrates Hau Hsu's 2023 RVV work under a unified
ifunc-based framework. A vectorized version (__memset_vector) is added
alongside the generic fallback (__memset_generic). The runtime resolver
selects the RVV variant when RISCV_HWPROBE_KEY_IMA_EXT_0 reports vector
support (RVV).
Currently, the resolver still selects the RVV variant even when the RVV
extension is disabled via prctl(). As a consequence, any process that
has RVV disabled via prctl() will receive SIGILL when calling memset().
Co-authored-by: Jerry Shih <jerry.shih@sifive.com>
Co-authored-by: Jeff Law <jeffreyalaw@gmail.com>
Signed-off-by: Yao Zihong <zihong.plct@isrc.iscas.ac.cn>
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
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 <hjl.tools@gmail.com>
The setup_vdso assumes that vDSO will contain only one PT_LOAD segment
and that 0 is the sentinel for the start mapping address. Although
the kernel avoids adding more than one PT_LOAD to avoid compatibility
issues, there is no impending issue that prevents glibc from supporting
vDSO with multiple PT_LOAD (as some wrapper tools do [1]).
To support multiple PT_LOAD segments, replace the sentinel with a bool
to indicate that the VMA start has already been set.
Testing is really tricky, since the bug report does not indicate which
tool was used to trigger the issue, nor a runtime that provides a vDSO
with multiple PT_LOAD. I had to modify the qemu user with a custom
script to create 2 PT_LOAD sections, remove checks that prevent the
vDSO object from being created, and remove the load bias adjustment
in load_elf_vdso. I could not come up with an easy test case to
integrate with glibc.
The Linux kernel provides vDSO with only one PT_LOAD due to
compatibility reasons. For instance
* arch/arm64/kernel/vdso/vdso.lds.S
86 /*
87 * We must supply the ELF program headers explicitly to get just one
88 * PT_LOAD segment, and set the flags explicitly to make segments read-only.
89 /
90 PHDRS
91 {
92 text PT_LOAD FLAGS(5) FILEHDR PHDRS; / PF_R|PF_X /
93 dynamic PT_DYNAMIC FLAGS(4); / PF_R /
94 note PT_NOTE FLAGS(4); / PF_R */
95 }
* arch/x86/entry/vdso/vdso-layout.lds.S
95 /*
96 * We must supply the ELF program headers explicitly to get just one
97 * PT_LOAD segment, and set the flags explicitly to make segments read-only.
98 /
99 PHDRS
100 {
101 text PT_LOAD FLAGS(5) FILEHDR PHDRS; / PF_R|PF_X /
102 dynamic PT_DYNAMIC FLAGS(4); / PF_R /
103 note PT_NOTE FLAGS(4); / PF_R */
104 eh_frame_hdr PT_GNU_EH_FRAME;
105 }
Checked on aarch64-linux-gnu.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32583#c2
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The pthread_join/pthread_timedjoin_np/pthread_clockjoin_np will not act
on cancellation if 1. some other thread is already waiting on the 'joinid'
or 2. If the thread has already exited.
On nptl/pthread_join_common.c, the 1. is due to the CAS doing an early
return:
80 else if (__glibc_unlikely (atomic_compare_exchange_weak_acquire (&pd->joinid,
81 &self,
82 NULL)))
83 /* There is already somebody waiting for the thread. */
84 return EINVAL;
And 2. is due to the pd->tid equal to 0:
99 pid_t tid;
100 while ((tid = atomic_load_acquire (&pd->tid)) != 0)
101 {
The easiest solution would be to add an __pthread_testcancel () on
__pthread_clockjoin_ex () if 'cancel' is true.
Checked on aarch64-linux-gnu, arm-linux-gnueabihf, x86_64-linux-gnu,
and i686-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Same as support_process_state_wait, but wait for the task TID
(obtained with gettid) from the current process. Since the kernel
might remove the /proc/<pid>/task/<tid>/status at any time if the
thread terminates, the code needs to handle possible
fopen/getline/fclose failures due to an inexistent file.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
And use the new __pthread_descriptor_valid function that checks
for 'joinstate' to get the thread state instead of 'tid'. The
joinstate is set by the kernel when the thread exits.
Checked on x86_64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The use-after-free described in BZ#19951 is due to the use of two
different PD fields, 'joinid' and 'cancelhandling', to describe the
thread state and to synchronise the calls of pthread_join,
pthread_detach, pthread_exit, and normal thread exit.
Any state change may require checking both fields atomically to handle
partial state (e.g., pthread_join() with a cancellation handler to
issue a 'joinstate' field rollback).
This patch uses a different PD member with 4 possible states (JOINABLE,
DETACHED, EXITING, and EXITED) instead of the pthread 'tid' field, with
the following logic:
1. On pthread_create, the initial state is set either to JOINABLE or
DETACHED depending on the pthread attribute used.
2. On pthread_detach, a CAS is issued on the state. If the CAS fails,
the thread is already detached (DETACHED) or being terminated (EXITING).
For the former, an EINVAL is returned; for the latter, pthread_detach
should be responsible for joining the thread (and for deallocating any
internal resources).
3. In the exit phase of the wrapper function for the thread start routine
(reached either if the thread function has returned, pthread_exit has
been called, or cancellation handled has been acted upon), we issue a
CAS on state to set it to the EXITING mode.
If the thread is previously in DETACHED mode, the thread is responsible
for deallocating any resources; otherwise, the thread must be joined
(detached threads cannot deallocate themselves immediately).
4. The clear_tid_field on 'clone' call is changed to set the new 'state'
field on thread exit (EXITED). This state is only reached at thread
termination.
5. The pthread_join implementation is now simpler: the futex wait is done
directly on thread state, and there is no need to reset it in case of
timeout since the state is now set either by pthread_detach() or by the
kernel on process termination.
The race condition on pthread_detach is avoided with a single atomic
operation on the PD state: once the mode is set to THREAD_STATE_DETACHED, it
is up to the thread itself to deallocate its memory (done during the exit
phase at pthread_create()).
Also, the INVALID_NOT_TERMINATED_TD_P is removed since a negative yid is
not possible, and the macro is not used anywhere.
This change triggers an invalid C11 thread test: it creates a thread that
detaches, and after a timeout, the creating thread checks whether the join
fails. The issue is that once thrd_join() is called, the thread's lifetime
is not defined.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu,
arm-linux-gnueabihf, and powerpc64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
It is required by POSIX XSH 2.9.5 Thread Cancellation under the
heading Thread Cancellation Cleanup Handlers.
Checked x86_64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The pthread_create is annotated as __THROWNL.
Checked on x86_64-linux-gnu.
Suggested-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The recent commit 638d437dbf
"Deprecate s390-linux-gnu (31bit)"
leads to:
FAIL: compilers-s390x-linux-gnu gcc build
when it tries to build 31bit libgcc.
The build is fixed by explicitely disabling multilib.
GCC 12 is currently the minimum supported compiler version.
Remove no longer needed __GNUC_PREREQ (6, 0) test and corresponding
dead code from tls.h.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Check lock availability before acquisition to reduce cache line
bouncing. Significantly improves trylock throughput on multi-core
systems under heavy contention.
Tested on x86_64.
Fixes BZ #33704.
Co-authored-by: Alex M Wells <alex.m.wells@intel.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
The configure check might ignore if compiler driver warns that the
option is no support, so force fatal warnings.
If fixes the elf/tst-plt-rewrite{1,2} regressions when ld.lld is used.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The multiplication operation is required only if the branch is taken,
and the compiler might not optimize it away.
It fixes the following issues when the testcase is built with clang:
FAIL: math/test-ldouble-erf
Failure: erf (-0x4p-16384): Exception "Underflow" set
Failure: erf (0x1p-10000): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded54f38760a41abb84p-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded54f38760a41abb88p-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded54f4p-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded54f8p-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded5518p-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded551cp-16384): Exception "Underflow" set
Failure: erf (0x3.8b7f12369ded552p-16384): Exception "Underflow" set
Failure: erf (0x4p-16384): Exception "Underflow" set
Failure: erf_downward (-0x4p-16384): Exception "Underflow" set
Failure: erf_downward (0x1p-10000): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded54f38760a41abb84p-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded54f38760a41abb88p-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded54f4p-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded54f8p-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded5518p-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded551cp-16384): Exception "Underflow" set
Failure: erf_downward (0x3.8b7f12369ded552p-16384): Exception "Underflow" set
Failure: erf_downward (0x4p-16384): Exception "Underflow" set
Failure: erf_towardzero (-0x4p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x1p-10000): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded54f38760a41abb84p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded54f38760a41abb88p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded54f4p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded54f8p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded5518p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded551cp-16384): Exception "Underflow" set
Failure: erf_towardzero (0x3.8b7f12369ded552p-16384): Exception "Underflow" set
Failure: erf_towardzero (0x4p-16384): Exception "Underflow" set
Failure: erf_upward (-0x4p-16384): Exception "Underflow" set
Failure: erf_upward (0x1p-10000): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded54f38760a41abb84p-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded54f38760a41abb88p-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded54f4p-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded54f8p-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded5518p-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded551cp-16384): Exception "Underflow" set
Failure: erf_upward (0x3.8b7f12369ded552p-16384): Exception "Underflow" set
Failure: erf_upward (0x4p-16384): Exception "Underflow" set
Checked on x86_64-linux-gnu and aarch64-linux-gnu with gcc-15 and
clang-18.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Reinstate HAVE_64B_ATOMICS configure check that was reverted by commit
7fec8a5de6 due to BZ #33632. This was
fixed by 3dd2cbfa35 by only allowing
64-bit atomics on sem_t if its type is 8-byte aligned. Rebase and add
in cleanups in include/atomic.h that were omitted.
Fix an issue with sparcv8-linux-gnu-leon3 forcing -mcpu=v8 for rtld.c which
overrules -mcpu=leon3 and causes __atomic_always_lock_free (4, 0) to
incorrectly return 0 and trigger asserts in atomics. Remove this as it
seems to be a workaround for an issue in 1997.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cleanup thp_init, change it so that the DEFAULT_THP_PAGESIZE
setting can be overridden with glibc.malloc.hugetlb=0 tunable.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Sachin Monga
Adhemerval Zanella
Yury Khrustalev
Samuel Thibault
Xi Ruoyao
Florian Weimer
Joan Lledó
Paul Eggert
Siddhesh Poyarekar
caiyinyu
Sergey Kolosov
Yao Zihong
Stefan Liebler
Uros Bizjak
Sunil K Pandey
Wilco Dijkstra