about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* Use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sourcesFlorian Weimer2022-10-1850-158/+20
| | | | | | | | | | | | | | | | | In the future, this will result in a compilation failure if the macros are unexpectedly undefined (due to header inclusion ordering or header inclusion missing altogether). Assembler sources are more difficult to convert. In many cases, they are hand-optimized for the mangling and no-mangling variants, which is why they are not converted. sysdeps/s390/s390-32/__longjmp.c and sysdeps/s390/s390-64/__longjmp.c are special: These are C sources, but most of the implementation is in assembler, so the PTR_DEMANGLE macro has to be undefined in some cases, to match the assembler style. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Introduce <pointer_guard.h>, extracted from <sysdep.h>Florian Weimer2022-10-18131-531/+939
| | | | | | | | | | | | | | This allows us to define a generic no-op version of PTR_MANGLE and PTR_DEMANGLE. In the future, we can use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources, avoiding an unintended loss of hardening due to missing include files or unlucky header inclusion ordering. In i386 and x86_64, we can avoid a <tls.h> dependency in the C code by using the computed constant from <tcb-offsets.h>. <sysdep.h> no longer includes these definitions, so there is no cyclic dependency anymore when computing the <tcb-offsets.h> constants. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86-64: Move LP_SIZE definition to its own headerFlorian Weimer2022-10-184-11/+48
| | | | | | | | | This way, we can define the pointer guard macros without including <sysdep.h> on x86-64. Other architectures will not have such an inclusion dependency, and the implied header file inclusion would create a porting hazard. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* math: Fix asin and acos invalid exception with old gccSzabolcs Nagy2022-10-171-16/+2
| | | | | | | | | | | | | | This works around a gcc issue where it const folded inf/inf into nan, preventing the invalid exception to be signalled. (x-x)/(x-x) is more robust against optimizations and works for all out of bounds values including x==nan. The gcc issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 should be fixed on release branches starting from gcc-10, but it is better to change the code in case glibc is built with older gcc. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* x86: Update strlen-evex-base to use new reg/vec macros.Noah Goldstein2022-10-142-76/+44
| | | | | | | | | | To avoid duplicate the VMM / GPR / mask insn macros in all incoming evex512 files use the macros defined in 'reg-macros.h' and '{vec}-macros.h' This commit does not change libc.so Tested build on x86-64
* x86: Remove now unused vec header macros.Noah Goldstein2022-10-147-328/+0
| | | | | | This commit does not change libc.so Tested build on x86-64
* x86: Update memset to use new VEC macrosNoah Goldstein2022-10-146-99/+43
| | | | | | | | Replace %VEC(n) -> %VMM(n) This commit does not change libc.so Tested build on x86-64
* x86: Update memmove to use new VEC macrosNoah Goldstein2022-10-146-221/+132
| | | | | | | | Replace %VEC(n) -> %VMM(n) This commit does not change libc.so Tested build on x86-64
* x86: Update memrchr to use new VEC macrosNoah Goldstein2022-10-141-21/+21
| | | | | | | | Replace %VEC(n) -> %VMM(n) This commit does not change libc.so Tested build on x86-64
* x86: Update VEC macros to complete API for evex/evex512 implsNoah Goldstein2022-10-149-0/+635
| | | | | | | | | | | | | | | | | | | | | | | 1) Copy so that backport will be easier. 2) Make section only define if there is not a previous definition 3) Add `VEC_lo` definition for proper reg-width but in the ymm/zmm0-15 range. 4) Add macros for accessing GPRs based on VEC_SIZE This is to make it easier to do think like: ``` vpcmpb %VEC(0), %VEC(1), %k0 kmov{d|q} %k0, %{eax|rax} test %{eax|rax} ``` It adds macro s.t any GPR can get the proper width with: `V{upcase_GPR_name}` and any mask insn can get the proper width with: `{upcase_mask_insn_without_postfix}` This commit does not change libc.so Tested build on x86-64
* elf: Do not completely clear reused namespace in dlmopen (bug 29600)Florian Weimer2022-10-142-12/+30
| | | | | | | | | | | | | The data in the _ns_debug member must be preserved, otherwise _dl_debug_initialize enters an infinite loop. To be conservative, only clear the libc_map member for now, to fix bug 29528. Fixes commit d0e357ff45a75553dee3b17ed7d303bfa544f6fe ("elf: Call __libc_early_init for reused namespaces (bug 29528)"), by reverting most of it. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* malloc: Switch global_max_fast to uint8_tFlorian Weimer2022-10-131-1/+1
| | | | | | | | MAX_FAST_SIZE is 160 at most, so a uint8_t is sufficient. This makes it harder to use memory corruption, by overwriting global_max_fast with a large value, to fundamentally alter malloc behavior. Reviewed-by: DJ Delorie <dj@redhat.com>
* Add NT_S390_PV_CPU_DATA from Linux 6.0 to elf.hJoseph Myers2022-10-121-0/+1
| | | | | | | Add the new NT_S390_PV_CPU_DATA constant from Linux 6.0 to glibc's elf.h. Tested for x86_64.
* Add AArch64 HWCAP2_EBF16 from Linux 6.0 to bits/hwcap.hJoseph Myers2022-10-121-0/+1
| | | | | | | Linux 6.0 adds a new AArch64 HWCAP2 bit, HWCAP2_EBF16. Add this to glibc's bits/hwcap.h. Tested with build-many-glibcs.py for aarch64-linux-gnu.
* String: Improve test coverage for memchrSunil K Pandey2022-10-101-2/+5
| | | | | | This test improves memchr coverage near page boundary. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* elf: Remove -fno-tree-loop-distribute-patterns usage on dl-supportAdhemerval Zanella2022-10-1010-5/+222
| | | | | | | | | | | | | | Besides the option being gcc specific, this approach is still fragile and not future proof since we do not know if this will be the only optimization option gcc will add that transforms loops to memset (or any libcall). This patch adds a new header, dl-symbol-redir-ifunc.h, that can b used to redirect the compiler generated libcalls to port the generic memset implementation if required. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* socket: Use offsetof in SUN_LEN (bug 29578)Andreas Schwab2022-10-101-1/+2
| | | | | Use offsetof instead of its traditional expansion in the definition of the SUN_LEN macro, to avoid a warning from the undefined behaviour sanitizer.
* Expose all MAP_ constants in <sys/mman.h> unconditionally (bug 29375)Andreas Schwab2022-10-1010-124/+90
| | | | | POSIX reserves the MAP_ prefix for <sys/mman.h>, so there is no need to conditionalize their definitions on feature test macros.
* LoongArch: Fix the condition to use PC-relative addressing in start.SXi Ruoyao2022-10-083-12/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
* arm: Enable USE_ATOMIC_COMPILER_BUILTINS (BZ #24774)Adhemerval Zanella2022-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per other architectures. I have checked on a armv8 hardware with the following configurations: arm-linux-gnueabihf (gcc built with --with-float=hard --with-cpu=arm926ej-s) armv5-linux-gnueabihf (-march=armv5te -mfpu=vfpv3) armv7-linux-gnueabihf (-march=armv7-a -mfpu=vfpv3) armv7-thumb-linux-gnueabihf (-march=armv7-a -mfpu=vfpv3 -mthumb) armv7-neon-linux-gnueabihf (-march=armv7-a -mfpu=neon) armv7-neonhard-linux-gnueabihf (-march=armv7-a -mfpu=neon -mfloat-abi=hard) Without any regression. I haven't dig into the code, but since Linux atomic-machine.h handle pre-ARMv6 and ARMv6 I expect the compiler might have some small room to optimize. The code size also improves is most of the configurations: * master text data bss dec hex filename 1727801 9720 37928 1775449 1b1759 arm-linux-gnueabihf/libc.so 1691729 9720 37928 1739377 1a8a71 arm-linux-gnueabihf-armv7-disable-multi-arch/libc.so 1725509 9720 37928 1773157 1b0e65 armv5-linux-gnueabihf/libc.so 1700757 9720 37928 1748405 1aadb5 armv6-linux-gnueabihf/libc.so 1698973 9720 37928 1746621 1aa6bd armv6t2-linux-gnueabihf/libc.so 1695481 9752 37928 1743161 1a9939 armv7-linux-gnueabihf/libc.so 1692917 9744 37928 1740589 1a8f2d armv7-neonhard-linux-gnueabihf/libc.so 1692917 9744 37928 1740589 1a8f2d armv7-neon-linux-gnueabihf/libc.so 1225353 9752 37928 1273033 136cc9 armv7-thumb-linux-gnueabihf/libc.so * patched text data bss dec hex filename 1726805 9720 37928 1774453 1b1375 arm-linux-gnueabihf/libc.so 1689321 9720 37928 1736969 1a8109 arm-linux-gnueabihf-armv7-disable-multi-arch/libc.so 1724433 9720 37928 1772081 1b0a31 armv5-linux-gnueabihf/libc.so 1698301 9720 37928 1745949 1aa41d armv6-linux-gnueabihf/libc.so 1696525 9720 37928 1744173 1a9d2d armv6t2-linux-gnueabihf/libc.so 1693009 9752 37928 1740689 1a8f91 armv7-linux-gnueabihf/libc.so 1690493 9744 37928 1738165 1a85b5 armv7-neonhard-linux-gnueabihf/libc.so 1690493 9744 37928 1738165 1a85b5 armv7-neon-linux-gnueabihf/libc.so 1223837 9752 37928 1271517 1366dd armv7-thumb-linux-gnueabihf/libc.so The idea is eventually move all architectures to use compiler builtins. Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net>
* csu: Disable stack protector for static-reloc for static-pieAdhemerval Zanella2022-10-061-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For instance on x86_64 with gcc 12.1.1 andwith fstack-protector enabled the empty function still generates a stack protector code sequence: 0000000000000000 <_dl_relocate_static_pie>: 0: 48 83 ec 18 sub $0x18,%rsp 4: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax b: 00 00 d: 48 89 44 24 08 mov %rax,0x8(%rsp) 12: 31 c0 xor %eax,%eax 14: 48 8b 44 24 08 mov 0x8(%rsp),%rax 19: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 20: 00 00 22: 75 05 jne 29 <_dl_relocate_static_pie+0x29> 24: 48 83 c4 18 add $0x18,%rsp 28: c3 ret 29: e8 00 00 00 00 call 2e <_dl_relocate_static_pie+0x2e> And since the function is called prior thread pointer setup, it triggers a invalid memory access (this is shown with the failure of elf/tst-tls1-static-non-pie). Although it might characterizes as compiler issue or missed optimization, to be safe also disables stack protector on static-reloc object. Checked on x86_64-linux-gnu and sparc64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* NEWS: Fix grammarAndreas Schwab2022-10-061-1/+1
|
* elf: Simplify output of hwcap subdirectories in ld.so helpJavier Pello2022-10-061-36/+7
| | | | | | | | | The print_hwcap_1 machinery was useful for the legacy hwcaps subdirectories, but it is not worth the trouble now that they are gone. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove _dl_string_hwcapJavier Pello2022-10-0610-83/+0
| | | | | | | | Removal of legacy hwcaps support from the dynamic loader left no users of _dl_string_hwcap. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Add NEWS entry for legacy hwcaps removalJavier Pello2022-10-061-1/+4
| | | | | | | | Add a NEWS entry noting the removal of the legacy hwcaps search mechanism for shared objects. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove hwcap and bits_hwcap fields from struct cache_entryJavier Pello2022-10-061-22/+6
| | | | | | | | They were set to 0 on initialisation and never changed later after last commit. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Remove hwcap parameter from add_to_cache signatureJavier Pello2022-10-063-16/+5
| | | | | | | | Last commit made it so that the value passed for that parameter was always 0 at its only call site. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Remove legacy hwcaps support from ldconfigJavier Pello2022-10-061-145/+10
| | | | | | | Remove support for the legacy hwcaps subdirectories from ldconfig. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Remove legacy hwcaps support from the dynamic loaderJavier Pello2022-10-063-212/+10
| | | | | | | | Remove support for the legacy hwcaps subdirectories from the dynamic loader. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* x86_64: Remove platform directory library loading testJavier Pello2022-10-063-64/+0
| | | | | | | | | This was to test loading of shared libraries from platform subdirectories, but this functionality is going away in the following commits. Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Update to Unicode 15.0.0 [BZ #29604]Mike FABIAN2022-10-0614-865/+1990
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unicode 15.0.0 Support: Character encoding, character type info, and transliteration tables are all updated to Unicode 15.0.0, using the generator scripts contributed by Mike FABIAN (Red Hat). Total added characters in newly generated CHARMAP: 4489 Total removed characters in newly generated WIDTH: 0 Total changed characters in newly generated WIDTH: 0 Total added characters in newly generated WIDTH: 4257 alpha: Added 4389 characters in new ctype which were not in old ctype combining: Added 42 characters in new ctype which were not in old ctype combining_level3: Added 34 characters in new ctype which were not in old ctype graph: Added 4489 characters in new ctype which were not in old ctype lower: Added 73 characters in new ctype which were not in old ctype print: Added 4489 characters in new ctype which were not in old ctype punct: Missing 5 characters of old ctype in new ctype punct: Missing: ఄ 0xc04 TELUGU SIGN COMBINING ANUSVARA ABOVE punct: Missing: ྂ 0xf82 TIBETAN SIGN NYI ZLA NAA DA punct: Missing: ྃ 0xf83 TIBETAN SIGN SNA LDAN punct: Missing: 𑂀 0x11080 KAITHI SIGN CANDRABINDU punct: Missing: 𑂁 0x11081 KAITHI SIGN ANUSVARA That’s OK, because these are now Alphabetic in DerivedCoreProperties.txt punct: Added 105 characters in new ctype which were not in old ctype Resolves: BZ #29604 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update kernel version to 6.0 in header constant testsJoseph Myers2022-10-053-4/+4
| | | | | | | | | This patch updates the kernel version in the tests tst-mman-consts.py, tst-mount-consts.py and tst-pidfd-consts.py to 6.0. (There are no new constants covered by these tests in 6.0 that need any other header changes.) Tested with build-many-glibcs.py.
* x86: Fix -Os build (BZ #29576)Adhemerval Zanella Netto2022-10-051-0/+18
| | | | | | | | | | | The compiler might transform __stpcpy calls (which are routed to __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy multiarch implementation does not build any working symbol due ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). Checked on x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* sunrpc: Suppress GCC -Os warning on user2netnameAdhemerval Zanella Netto2022-10-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | GCC with -Os warns that sprint might overflow: netname.c: In function ‘user2netname’: netname.c:51:28: error: ‘%s’ directive writing up to 255 bytes into a region of size between 239 and 249 [-Werror=format-overflow=] 51 | sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); | ^~ ~~~~~~~ netname.c:51:3: note: ‘sprintf’ output between 8 and 273 bytes into a destination of size 256 51 | sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors However the code does test prior the sprintf call that dfltdom plus the required extra space for OPSYS, uid, and extra character will not overflow and return 0 instead. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* rt: Initialize mq_send input on tst-mqueue{5,6}Adhemerval Zanella Netto2022-10-052-2/+2
| | | | | | | | | | | GCC with -Os warns that the mq_send input may be used uninitialized. Although for the tests the data content sent is not important, since both tests checks only if mq_notify was properly set, the warning is correct and data is indeed uninitialized. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* posix: Suppress -Os may be used uninitialized warnings on regexecAdhemerval Zanella Netto2022-10-051-0/+6
| | | | | | | | GCC with -Os issues may uninitialized warnings on regexec code. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* posix: Suppress -Os warnings on fnmatchAdhemerval Zanella Netto2022-10-051-0/+31
| | | | | | | | | | GCC with -Os issues some may uninitialized warnings on fnmatch code. All of the variables are already set when they are accessed on the loop prior. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* locale: prevent maybe-uninitialized errors with -Os [BZ #19444]Martin Jansa2022-10-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | Fixes following error when building with -Os: | In file included from strcoll_l.c:43: | strcoll_l.c: In function '__strcoll_l': | ../locale/weight.h:31:26: error: 'seq2.back_us' may be used uninitialized in this function [-Werror=maybe-uninitialized] | int_fast32_t i = table[*(*cpp)++]; | ^~~~~~~~~ | strcoll_l.c:304:18: note: 'seq2.back_us' was declared here | coll_seq seq1, seq2; | ^~~~ | In file included from strcoll_l.c:43: | ../locale/weight.h:31:26: error: 'seq1.back_us' may be used uninitialized in this function [-Werror=maybe-uninitialized] | int_fast32_t i = table[*(*cpp)++]; | ^~~~~~~~~ | strcoll_l.c:304:12: note: 'seq1.back_us' was declared here | coll_seq seq1, seq2; | ^~~~ Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Regenerate sysdeps/mach/hurd/bits/errno.hJoseph Myers2022-10-051-0/+1
| | | | | | | This addition to the list of source headers in sysdeps/mach/hurd/bits/errno.h appears in the source tree after build-many-glibcs.py runs, I'm guessing resulting from gnumach commit c566ad85a2d6728ebc8ec0f461a3b35df300e96e.
* Update syscall lists for Linux 6.0Joseph Myers2022-10-051-2/+2
| | | | | | | Linux 6.0 has no new syscalls. Update the version number in syscall-names.list to reflect that it is still current for 6.0. Tested with build-many-glibcs.py.
* nscd: Drop local address tuple variable [BZ #29607]Siddhesh Poyarekar2022-10-041-3/+2
| | | | | | | | | | | | | | | When a request needs to be resent (e.g. due to insufficient buffer space), the references to subsequent tuples in the local variable are stale and should not be used. This used to work by accident before, but since 1d495912a it no longer does. Instead of trying to reset it, just let gethostbyname4_r write into TUMPBUF6 for us, thus maintaining a consistent state at all times. This is now consistent with what is done in gaih_inet for getaddrinfo. Resolves: BZ #29607 Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Use Linux 6.0 in build-many-glibcs.pyJoseph Myers2022-10-041-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 6.0. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* x86-64: Require BMI1/BMI2 for AVX2 strrchr and wcsrchr implementationsAurelien Jarno2022-10-033-3/+16
| | | | | | | | | | | The AVX2 strrchr and wcsrchr implementation uses the 'blsmsk' instruction which belongs to the BMI1 CPU feature and the 'shrx' instruction, which belongs to the BMI2 CPU feature. Fixes: df7e295d18ff ("x86: Optimize {str|wcs}rchr-avx2") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 and LZCNT for AVX2 memrchr implementationAurelien Jarno2022-10-033-2/+10
| | | | | | | | | | | The AVX2 memrchr implementation uses the 'shlxl' instruction, which belongs to the BMI2 CPU feature and uses the 'lzcnt' instruction, which belongs to the LZCNT CPU feature. Fixes: af5306a735eb ("x86: Optimize memrchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 (raw|w)memchr implementationsAurelien Jarno2022-10-031-3/+9
| | | | | | | | | | The AVX2 memchr, rawmemchr and wmemchr implementations use the 'bzhi' and 'sarx' instructions, which belongs to the BMI2 CPU feature. Fixes: acfd088a1963 ("x86: Optimize memchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 wcs(n)cmp implementationsAurelien Jarno2022-10-031-2/+6
| | | | | | | | | | | | | | The AVX2 wcs(n)cmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 strncmp implementationAurelien Jarno2022-10-032-4/+7
| | | | | | | | | | | | | | The AVX2 strncmp implementations uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 strcmp implementationAurelien Jarno2022-10-032-3/+5
| | | | | | | | | | | | | | The AVX2 strcmp implementation uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86-64: Require BMI2 for AVX2 str(n)casecmp implementationsAurelien Jarno2022-10-032-8/+21
| | | | | | | | | | | | | | The AVX2 str(n)casecmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* x86: include BMI1 and BMI2 in x86-64-v3 levelAurelien Jarno2022-10-031-0/+2
| | | | | | | | The "System V Application Binary Interface AMD64 Architecture Processor Supplement" mandates the BMI1 and BMI2 CPU features for the x86-64-v3 level. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-10-30 23:35:14 +0000