about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* aarch64: Add longjmp support for SMESzabolcs Nagy2024-01-021-0/+22
| | | | | | | | | | For the ZA lazy saving scheme to work, longjmp has to call __libc_arm_za_disable. In ld.so we assume ZA is not used so longjmp does not need special support there. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: Add SME runtime supportSzabolcs Nagy2024-01-023-3/+129
| | | | | | | | | | | | | | | | | | | The runtime support routines for the call ABI of the Scalable Matrix Extension (SME) are mostly in libgcc. Since libc.so cannot depend on libgcc_s.so have an implementation of __arm_za_disable in libc for libc internal use in longjmp and similar APIs. __libc_arm_za_disable follows the same PCS rules as __arm_za_disable, but it's a hidden symbol so it does not need variant PCS marking. Using __libc_fatal instead of abort because it can print a message and works in ld.so too. But for now we don't need SME routines in ld.so. To check the SME HWCAP in asm, we need the _dl_hwcap2 member offset in _rtld_global_ro in the shared libc.so, while in libc.a the _dl_hwcap2 object is accessed. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* localedata: convert uz_UZ and uz_UZ@cyrillic to UTF-8Mike FABIAN2024-01-022-56/+56
|
* localedata: uz_UZ and uz_UZ@cyrillic: Fix decimal point and thousands separatorMike FABIAN2024-01-022-4/+4
| | | | Resolves: BZ # 31204
* libio: Check remaining buffer size in _IO_wdo_write (bug 31183)Florian Weimer2024-01-021-1/+1
| | | | | | | | | | The multibyte character needs to fit into the remaining buffer space, not the already-written buffer space. Without the fix, we were never moving the write pointer from the start of the buffer, always using the single-character fallback buffer. Fixes commit 04b76b5aa8b2d1d19066e42dd1 ("Don't error out writing a multibyte character to an unbuffered stream (bug 17522)").
* getaddrinfo: translate ENOMEM to EAI_MEMORY (bug 31163)Andreas Schwab2024-01-021-1/+8
| | | | | When __resolv_context_get returns NULL due to out of memory, translate it to a return value of EAI_MEMORY.
* string: Add additional output in test-strchr failureNoah Goldstein2024-01-011-5/+12
| | | | | | | | Seeing occasional failures in `__strchrnul_evex512` that are not consistently reproducible. Hopefully by adding this the next failure will provide enough information to debug. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* Add a setjmp/longjmp test between user contextsH.J. Lu2024-01-012-0/+139
| | | | | | | | Verify that setjmp and longjmp work correctly between user contexts. Arrange stacks for uctx_func1 and uctx_func2 so that ____longjmp_chk works when setjmp and longjmp are called from different user contexts. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86/cet: Add -fcf-protection=none before -fcf-protection=branchH.J. Lu2024-01-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When shadow stack is enabled, some CET tests failed when compiled with GCC 14: FAIL: elf/tst-cet-legacy-4 FAIL: elf/tst-cet-legacy-5a FAIL: elf/tst-cet-legacy-6a which are caused by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 These tests use -fcf-protection -fcf-protection=branch and assume that -fcf-protection=branch will override -fcf-protection. But this GCC 14 commit: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1c6231c05bdcca changed the -fcf-protection behavior such that -fcf-protection -fcf-protection=branch is treated the same as -fcf-protection Use -fcf-protection -fcf-protection=none -fcf-protection=branch as the workaround. This fixes BZ #31187. Tested with GCC 13 and GCC 14 on Intel Tiger Lake. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* Regenerate libc.potAndreas K. Hüttel2024-01-011-159/+173
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* Omit regex.c pragmas no longer neededPaul Eggert2024-01-011-4/+0
| | | | | | | | | * posix/regex.c: [!_LIBC && __GNUC_PREREQ (4, 3)]: Omit GCC pragmas no longer needed when this file is used as part of Gnulib. -Wold-style-definition no longer needs to be ignored because the regex code no longer uses old style definitions. -Wtype-limits no longer needs to be ignored because Gnulib already arranges for it to be ignored in the C compiler flags. This patch is taken from Gnulib.
* Update copyright dates not handled by scripts/update-copyrightsPaul Eggert2024-01-0121-21/+21
| | | | | | I've updated copyright dates in glibc for 2024. This is the patch for the changes not generated by scripts/update-copyrights and subsequent build / regeneration of generated files.
* Update copyright in generated files by running "make"Paul Eggert2024-01-012-2/+2
|
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-0112589-12621/+12621
|
* x86/cet: Run some CET tests with shadow stackH.J. Lu2024-01-014-0/+17
| | | | | | | When CET is disabled by default, run some CET tests with shadow stack enabled using $ export GLIBC_TUNABLES=glibc.cpu.hwcaps=SHSTK
* x86/cet: Don't set CET active by defaultH.J. Lu2024-01-012-2/+15
| | | | | | | | | | | | | | | Not all CET enabled applications and libraries have been properly tested in CET enabled environments. Some CET enabled applications or libraries will crash or misbehave when CET is enabled. Don't set CET active by default so that all applications and libraries will run normally regardless of whether CET is active or not. Shadow stack can be enabled by $ export GLIBC_TUNABLES=glibc.cpu.hwcaps=SHSTK at run-time if shadow stack can be enabled by kernel. NB: This commit can be reverted if it is OK to enable CET by default for all applications and libraries.
* x86/cet: Check feature_1 in TCB for active IBT and SHSTKH.J. Lu2024-01-013-1/+35
| | | | | | | | | Initially, IBT and SHSTK are marked as active when CPU supports them and CET are enabled in glibc. They can be disabled early by tunables before relocation. Since after relocation, GLRO(dl_x86_cpu_features) becomes read-only, we can't update GLRO(dl_x86_cpu_features) to mark IBT and SHSTK as inactive. Instead, check the feature_1 field in TCB to decide if IBT and SHST are active.
* x86/cet: Enable shadow stack during startupH.J. Lu2024-01-0110-146/+175
| | | | | | | | | | | | | | | | | | | | | | | Previously, CET was enabled by kernel before passing control to user space and the startup code must disable CET if applications or shared libraries aren't CET enabled. Since the current kernel only supports shadow stack and won't enable shadow stack before passing control to user space, we need to enable shadow stack during startup if the application and all shared library are shadow stack enabled. There is no need to disable shadow stack at startup. Shadow stack can only be enabled in a function which will never return. Otherwise, shadow stack will underflow at the function return. 1. GL(dl_x86_feature_1) is set to the CET features which are supported by the processor and are not disabled by the tunable. Only non-zero features in GL(dl_x86_feature_1) should be enabled. After enabling shadow stack with ARCH_SHSTK_ENABLE, ARCH_SHSTK_STATUS is used to check if shadow stack is really enabled. 2. Use ARCH_SHSTK_ENABLE in RTLD_START in dynamic executable. It is safe since RTLD_START never returns. 3. Call arch_prctl (ARCH_SHSTK_ENABLE) from ARCH_SETUP_TLS in static executable. Since the start function using ARCH_SETUP_TLS never returns, it is safe to enable shadow stack in ARCH_SETUP_TLS.
* elf: Always provide _dl_get_dl_main_map in libc.aH.J. Lu2024-01-012-6/+3
| | | | | Always provide _dl_get_dl_main_map in libc.a. It will be used by x86 to process PT_GNU_PROPERTY segment.
* x86/cet: Sync with Linux kernel 6.6 shadow stack interfaceH.J. Lu2024-01-0115-133/+173
| | | | | | | | | | | | | | | | | | | | | | | Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is supported, i386 shadow stack codes are unchanged and CET shouldn't be enabled for i386. 1. When the shadow stack base in TCB is unset, the default shadow stack is in use. Use the current shadow stack pointer as the marker for the default shadow stack. It is used to identify if the current shadow stack is the same as the target shadow stack when switching ucontexts. If yes, INCSSP will be used to unwind shadow stack. Otherwise, shadow stack restore token will be used. 2. Allocate shadow stack with the map_shadow_stack syscall. Since there is no function to explicitly release ucontext, there is no place to release shadow stack allocated by map_shadow_stack in ucontext functions. Such shadow stacks will be leaked. 3. Rename arch_prctl CET commands to ARCH_SHSTK_XXX. 4. Rewrite the CET control functions with the current kernel shadow stack interface. Since CET is no longer enabled by kernel, a separate patch will enable shadow stack during startup.
* RISC-V: Add support for dl_runtime_profile (BZ #31151)Aurelien Jarno2023-12-304-1/+225
| | | | | | | | | | | | | Code is mostly inspired from the LoongArch one, which has a similar ABI, with minor changes to support riscv32 and register differences. This fixes elf/tst-sprof-basic. This also fixes elf/tst-audit1, elf/tst-audit2 and elf/tst-audit8 with recent binutils snapshots when --enable-bind-now is used. Resolves: BZ #31151 Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
* debug: Add fortify wprintf testsAdhemerval Zanella2023-12-292-0/+106
| | | | | | | Similar to other printf-like ones. It requires to be in a different process so we can change the orientation of stdout. Checked on aarch64, armhf, x86_64, and i686.
* debug: Add fortify syslog testsAdhemerval Zanella2023-12-292-0/+133
| | | | | | | | | | | It requires to be in a container tests to avoid logging bogus information on the system. The syslog also requires to be checked in a different process because the internal printf call will abort with the internal syslog lock taken (which makes subsequent syslog calls deadlock). Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* debug: Add fortify dprintf testsAdhemerval Zanella2023-12-291-0/+22
| | | | | | | Similar to other printf-like ones. Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* debug: Increase tst-fortify checks for compiler without __va_arg_pack supportAdhemerval Zanella2023-12-291-5/+1
| | | | | | | | The fortify wrappers for varargs functions already add fallbacks to builtins calls if __va_arg_pack is not supported. Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* debug: Adapt fortify tests to libsupportAdhemerval Zanella2023-12-296-40/+39
| | | | | Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* localedata: yo_NT: remove redundant commentsMike FABIAN2023-12-261-8/+0
| | | | See: https://sourceware.org/pipermail/libc-alpha/2023-December/153538.html
* localedata: convert en_AU, en_NZ, mi_NZ, niu_NZ to UTF-8Mike FABIAN2023-12-264-22/+22
|
* localedata: First day of the week in AU is Monday, LC_TIME in en_NZ is ↵Mike FABIAN2023-12-262-34/+2
| | | | | | identical to LC_TIME in en_AU then Resolves: BZ # 24877
* localedata: convert yo_NG to UTF-8, check that language name in Yoruba ↵Mike FABIAN2023-12-251-44/+44
| | | | | | agrees with CLDR Related: BZ # 24878
* x86-64: Fix the tcb field load for x32 [BZ #31185]H.J. Lu2023-12-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | _dl_tlsdesc_undefweak and _dl_tlsdesc_dynamic access the thread pointer via the tcb field in TCB: _dl_tlsdesc_undefweak: _CET_ENDBR movq 8(%rax), %rax subq %fs:0, %rax ret _dl_tlsdesc_dynamic: ... subq %fs:0, %rax movq -8(%rsp), %rdi ret Since the tcb field in TCB is a pointer, %fs:0 is a 32-bit location, not 64-bit. It should use "sub %fs:0, %RAX_LP" instead. Since _dl_tlsdesc_undefweak returns ptrdiff_t and _dl_make_tlsdesc_dynamic returns void *, RAX_LP is appropriate here for x32 and x86-64. This fixes BZ #31185.
* x86-64: Fix the dtv field load for x32 [BZ #31184]H.J. Lu2023-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x32, I got FAIL: elf/tst-tlsgap $ gdb elf/tst-tlsgap ... open tst-tlsgap-mod1.so Thread 2 "tst-tlsgap" received signal SIGSEGV, Segmentation fault. [Switching to LWP 2268754] _dl_tlsdesc_dynamic () at ../sysdeps/x86_64/dl-tlsdesc.S:108 108 movq (%rsi), %rax (gdb) p/x $rsi $4 = 0xf7dbf9005655fb18 (gdb) This is caused by _dl_tlsdesc_dynamic: _CET_ENDBR /* Preserve call-clobbered registers that we modify. We need two scratch regs anyway. */ movq %rsi, -16(%rsp) movq %fs:DTV_OFFSET, %rsi Since the dtv field in TCB is a pointer, %fs:DTV_OFFSET is a 32-bit location, not 64-bit. Load the dtv field to RSI_LP instead of rsi. This fixes BZ #31184.
* nss: Remove unused allocation from get_nscd_addresses in getaddrinfoFlorian Weimer2023-12-201-1/+0
| | | | | | | No bug because this is not visible if glibc is built with optimization. Otherwise this would be a critical resource leak. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* x86/cet: Don't disable CET if not single threadedH.J. Lu2023-12-201-2/+9
| | | | | | | | In permissive mode, don't disable IBT nor SHSTK when dlopening a legacy shared library if not single threaded since IBT and SHSTK may be still enabled in other threads. Other threads with IBT or SHSTK enabled will crash when calling functions in the legacy shared library. Instead, an error will be issued.
* x86: Modularize sysdeps/x86/dl-cet.cH.J. Lu2023-12-201-176/+280
| | | | | | | | | | | Improve readability and make maintenance easier for dl-feature.c by modularizing sysdeps/x86/dl-cet.c: 1. Support processors with: a. Only IBT. Or b. Only SHSTK. Or c. Both IBT and SHSTK. 2. Lock CET features only if IBT or SHSTK are enabled and are not enabled permissively.
* x86/cet: Update tst-cet-vfork-1H.J. Lu2023-12-201-26/+17
| | | | | Change tst-cet-vfork-1.c to verify that vfork child return triggers SIGSEGV due to shadow stack mismatch.
* elf: Add TLS modid reuse test for bug 29039Szabolcs Nagy2023-12-205-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a minimal regression test for bug 29039 which only affects targets with TLSDESC and a reproducer requires that 1) Have modid gaps (closed modules) with old generation. 2) Update a DTV to a newer generation (needs a newer dlopen). 3) But do not update the closed gap entry in that DTV. 4) Reuse the modid gap for a new module (another dlopen). 5) Use dynamic TLSDESC in that new module with old generation (bug). 6) Access TLS via this TLSDESC and the now outdated DTV. However step (3) in practice rarely happens: during DTV update the entries for closed modids are initialized to "unallocated" and then dynamic TLSDESC calls __tls_get_addr independently of its generation. The only exception to this is DTV setup at thread creation (gaps are initialized to NULL instead of unallocated) or DTV resize where the gap entries are outside the previous DTV array (again NULL instead of unallocated, and this requires loading > DTV_SURPLUS modules). So the bug can only cause NULL (+ offset) dereference, not use after free. And the easiest way to get (3) is via thread creation. Note that step (5) requires that the newly loaded module has larger TLS than the remaining optional static TLS. And for (6) there cannot be other TLS access or dlopen in the thread that updates the DTV. Tested on aarch64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: Add SIMD attributes to math functions with vector versionsJoe Ramsay2023-12-202-0/+113
| | | | | | | Added annotations for autovec by GCC and GFortran - this enables GCC >= 9 to autovectorise math calls at -Ofast. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* aarch64: Add half-width versions of AdvSIMD f32 libmvec routinesJoe Ramsay2023-12-2020-14/+125
| | | | | | | | | | | Compilers may emit calls to 'half-width' routines (two-lane single-precision variants). These have been added in the form of wrappers around the full-width versions, where the low half of the vector is simply duplicated. This will perform poorly when one lane triggers the special-case handler, as there will be a redundant call to the scalar version, however this is expected to be rare at Ofast. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* Fix elf/tst-env-setuid[-static] if test needs to be rerun.Stefan Liebler2023-12-203-6/+42
| | | | | | | | | | | | | | | | | | | | | | | | If /tmp is mounted nosuid and make xcheck is run, then tst-env-setuid fails UNSUPPORTED with "SGID failed: GID and EGID match" and /var/tmp/tst-sonamemove-runmod1.so.profile is created. If you then try to rerun the test with a suid mounted test-dir (the SGID binary is created in test-dir which defaults to /tmp) with something like that: make tst-env-setuid-ENV="TMPDIR=..." t=elf/tst-env-setuid test the test fails as the LD_PROFILE output file is still available from the previous run. Thus this patch removes the LD_PROFILE output file in parent before spawning the SGID binary. Even if LD_PROFILE is not supported anymore in static binaries, use a different library and thus output file for tst-env-setuid and tst-env-setuid-static in order to not interfere if both tests are run in parallel. Furthermore the checks in test_child are now more verbose. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Fix elf: Do not duplicate the GLIBC_TUNABLES stringH.J. Lu2023-12-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 2a969b53c0b02fed7e43473a92f219d737fd217a Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Wed Dec 6 10:24:01 2023 -0300 elf: Do not duplicate the GLIBC_TUNABLES string has @@ -38,7 +39,7 @@ which isn't available. */ #define CHECK_GLIBC_IFUNC_PREFERRED_OFF(f, cpu_features, name, len) \ _Static_assert (sizeof (#name) - 1 == len, #name " != " #len); \ - if (memcmp (f, #name, len) == 0) \ + if (tunable_str_comma_strcmp_cte (&f, #name) == 0) \ { \ cpu_features->preferred[index_arch_##name] \ &= ~bit_arch_##name; \ @@ -46,12 +47,11 @@ Fix it by removing "== 0" after tunable_str_comma_strcmp_cte.
* tst-setcontext10.c: Undef _FORTIFY_SOURCEH.J. Lu2023-12-191-0/+9
| | | | | | | | | | | When _FORTIFY_SOURCE is defined to 2, ____longjmp_chk is called, instead of longjmp. ____longjmp_chk compares the relative stack values to decide if it is called from a stack frame which called setjmp. If not, ____longjmp_chk assumes that an alternate signal stack is used. Since comparing the relative stack values isn't reliable with user context, when there is no signal, ____longjmp_chk will fail. Undefine _FORTIFY_SOURCE to avoid ____longjmp_chk in user context test.
* Fix elf: Do not duplicate the GLIBC_TUNABLES stringH.J. Lu2023-12-191-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix issues in sysdeps/x86/tst-hwcap-tunables.c added by Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Wed Dec 6 10:24:01 2023 -0300 elf: Do not duplicate the GLIBC_TUNABLES string 1. -AVX,-AVX2,-AVX512F should be used to disable AVX, AVX2 and AVX512. 2. AVX512 IFUNC functions check AVX512VL. -AVX512VL should be added to disable these functions. This fixed: FAIL: elf/tst-hwcap-tunables ... [0] Spawned test for -Prefer_ERMS,-Prefer_FSRM,-AVX,-AVX2,-AVX_Usable,-AVX2_Usable,-AVX512F_Usable,-SSE4_1,-SSE4_2,-SSSE3,-Fast_Unaligned_Load,-ERMS,-AVX_Fast_Unaligned_Load error: subprocess failed: tst-tunables error: unexpected output from subprocess ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false [1] Spawned test for ,-,-Prefer_ERMS,-Prefer_FSRM,-AVX,-AVX2,-AVX_Usable,-AVX2_Usable,-AVX512F_Usable,-SSE4_1,-SSE4_2,,-SSSE3,-Fast_Unaligned_Load,,-,-ERMS,-AVX_Fast_Unaligned_Load,-, error: subprocess failed: tst-tunables error: unexpected output from subprocess ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false ../sysdeps/x86/tst-hwcap-tunables.c:91: numeric comparison failure left: 1 (0x1); from: impls[i].usable right: 0 (0x0); from: false error: 2 test failures on Intel Tiger Lake.
* hppa: Fix undefined behaviour in feclearexcept (BZ 30983)Bruno Haible2023-12-191-1/+1
| | | | | | | | | | | | | | | | | | The expression (excepts & FE_ALL_EXCEPT) << 27 produces a signed integer overflow when 'excepts' is specified as FE_INVALID (= 0x10), because - excepts is of type 'int', - FE_ALL_EXCEPT is of type 'int', - thus (excepts & FE_ALL_EXCEPT) is (int) 0x10, - 'int' is 32 bits wide. The patched code produces the same instruction sequence as previosuly. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* alpha: Fix fesetexceptflag (BZ 30998)Bruno Haible2023-12-191-1/+1
| | | | | | | | It clears some exception flags that are outside the EXCEPTS argument. It fixes math/test-fexcept on qemu-user. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* riscv: Fix feenvupdate with FE_DFL_ENV (BZ 31022)Adhemerval Zanella2023-12-192-15/+124
| | | | | | | | | | | libc_feupdateenv_riscv should check for FE_DFL_ENV, similar to libc_fesetenv_riscv. Also extend the test-fenv.c to test fenvupdate. Checked on riscv under qemu-system. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* manual: Clarify undefined behavior of feenableexcept (BZ 31019)Bruno Haible2023-12-191-0/+6
| | | | | | Explain undefined behavior of feenableexcept in a special case. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* x86: Do not raises floating-point exception traps on fesetexceptflag (BZ 30990)Bruno Haible2023-12-193-32/+78
| | | | | | | | | | | | | | | | | | | According to ISO C23 (7.6.4.4), fesetexcept is supposed to set floating-point exception flags without raising a trap (unlike feraiseexcept, which is supposed to raise a trap if feenableexcept was called with the appropriate argument). The flags can be set in the 387 unit or in the SSE unit. When we need to clear a flag, we need to do so in both units, due to the way fetestexcept is implemented. When we need to set a flag, it is sufficient to do it in the SSE unit, because that is guaranteed to not trap. However, on i386 CPUs that have only a 387 unit, set the flags in the 387, as long as this cannot trap. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* i686: Do not raise exception traps on fesetexcept (BZ 30989)Adhemerval Zanella2023-12-194-25/+99
| | | | | | | | | | | | | | | | According to ISO C23 (7.6.4.4), fesetexcept is supposed to set floating-point exception flags without raising a trap (unlike feraiseexcept, which is supposed to raise a trap if feenableexcept was called with the appropriate argument). The flags can be set in the 387 unit or in the SSE unit. To set a flag, it is sufficient to do it in the SSE unit, because that is guaranteed to not trap. However, on i386 CPUs that have only a 387 unit, set the flags in the 387, as long as this cannot trap. Checked on i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* powerpc: Do not raise exception traps for fesetexcept/fesetexceptflag (BZ 30988)Adhemerval Zanella2023-12-194-16/+38
| | | | | | | | | | | | | | | | | | | | | | | According to ISO C23 (7.6.4.4), fesetexcept is supposed to set floating-point exception flags without raising a trap (unlike feraiseexcept, which is supposed to raise a trap if feenableexcept was called with the appropriate argument). This is a side-effect of how we implement the GNU extension feenableexcept, where feenableexcept/fesetenv/fesetmode/feupdateenv might issue prctl (PR_SET_FPEXC, PR_FP_EXC_PRECISE) depending of the argument. And on PR_FP_EXC_PRECISE, setting a floating-point exception flag triggers a trap. To make the both functions follow the C23, fesetexcept and fesetexceptflag now fail if the argument may trigger a trap. The math tests now check for an value different than 0, instead of bail out as unsupported for EXCEPTION_SET_FORCES_TRAP. Checked on powerpc64le-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-09 13:47:18 +0000