This change is identical to
26800a2c7e7996dc773b4e990dd5cca41c45e1a9 ("[sanitizer] Undef
_TIME_BITS along with _FILE_OFFSET_BITS on Linux"), but for
sanitizer_procmaps_solaris.cpp.
Indeed, even though sanitizer_procmaps_solaris.cpp is Solaris
specific, it also gets built on Linux platforms. It also includes
sanitizer_platform.h, which also ends up including features-time64.h,
causing a build failure on 32-bit Linux platforms on which 64-bit
time_t is enabled by setting _TIME_BITS=64.
To fix this, we do the same change: undefine _TIME_BITS, which anyway
will cause no harm as the rest of this file is inside a
SANITIZER_SOLARIS compile-time conditional.
Fixes:
In file included from /home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features.h:394,
from ../../../../libsanitizer/sanitizer_common/sanitizer_platform.h:25,
from ../../../../libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp:14:
/home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is al
lowed only with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^~~~~
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Closes: https://github.com/llvm/llvm-project/pull/99699
(cherry picked from commit a1217020da219386b29c1a5a4a217904ecf07d7d)
To Fix#110215
Interceptors introduced with 18a7ebda99044473fdbce6376993714ff54e6690
(cherry picked from commit d0b9c2c5647656738cda3fb670aa5d3b3a69d784)
`compiler-rt/lib/builtins/divtc3.c` and `multc3.c` don't compile on
Solaris/sparcv9 with `gcc -m32`:
```
FAILED: projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-sparc.dir/divtc3.c.o
[...]
compiler-rt/lib/builtins/divtc3.c: In function ‘__divtc3’:
compiler-rt/lib/builtins/divtc3.c:22:18: error: implicit declaration of function ‘__compiler_rt_logbtf’ [-Wimplicit-function-declaration]
22 | fp_t __logbw = __compiler_rt_logbtf(
| ^~~~~~~~~~~~~~~~~~~~
```
and many more. It turns out that while the definition of `__divtc3` is
guarded with `CRT_HAS_F128`, the `__compiler_rt_logbtf` and other
declarations use `CRT_HAS_128BIT && CRT_HAS_F128` as guard. This only
shows up with `gcc` since, as documented in Issue #41838, `clang`
violates the SPARC psABI in not using 128-bit `long double`, so this
code path isn't used.
Fixed by changing the guards to match.
Tested on `sparcv9-sun-solaris2.11`.
(cherry picked from commit 63a7786111c501920afc4cc27a4633f76cdaf803)
In these environments, the architecture name is armv7; recognize that
and enable the relevant runtimes.
Fix building the sanitizer_common library for this target, by using the
right registers for the architecture - this is similar to what
0c391133c9201ef29273554a1505ef855ce17668 did for aarch64.
(Still, address sanitizer doesn't support hooking functions at runtime
on armv7 or aarch64 - but other runtimes such as ubsan do work.)
(cherry picked from commit 5ea9dd8c7076270695a1d90b9c73718e7d95e0bf)
The CMake docs state that `check_c_source_compiles()` checks whether the
supplied code "can be compiled as a C source file and linked as an
executable (so it must contain at least a `main()` function)."
https://cmake.org/cmake/help/v3.30/module/CheckCSourceCompiles.html
In practice, this command is a wrapper around `try_compile()`:
- 2904ce00d2/Modules/CheckCSourceCompiles.cmake (L54)
- 2904ce00d2/Modules/Internal/CheckSourceCompiles.cmake (L101)
When `CMAKE_SOURCE_DIR` is compiler-rt/lib/builtins/,
`CMAKE_TRY_COMPILE_TARGET_TYPE` is set to `STATIC_LIBRARY`, so the
checks for `float16` and `bfloat16` support work as intended in a
Clang + compiler-rt runtime build for example, as it runs CMake
recursively from that directory.
However, when using llvm/ or compiler-rt/ as CMake source directory, as
`CMAKE_TRY_COMPILE_TARGET_TYPE` defaults to `EXECUTABLE`, these checks
will indeed fail if the code doesn't have a `main()` function. This
results in LLVM using x86 SIMD registers when generating calls to
builtins that, with Arch Linux's compiler-rt package for example,
actually use a GPR for their argument or return value as they use
`uint16_t` instead of `_Float16`.
This had been caught in post-commit review:
https://reviews.llvm.org/D145237#4521152. Use of the internal
`CMAKE_C_COMPILER_WORKS` variable is not what hides the issue, however.
PR #69842 tried to fix this by unconditionally setting
`CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY`, but it apparently
caused other issues, so it was reverted. This PR just adds a `main()`
function in the checks, as per the CMake docs.
(cherry picked from commit 68d8b3846ab1e6550910f2a9a685690eee558af2)
32-bit Windows uses `unsigned int` for uintptr_t and size_t.
Commit 18e06e3e2f3d47433e1ed323b8725c76035fc1ac changed uptr to
unsigned long, so it no longer matches the real size_t/uintptr_t and
therefore the current definition of usize result in:
`error C2821: first formal parameter to 'operator new' must be 'size_t'`
However, the real problem is that uptr is wrong to work around the fact
that we have local SIZE_T and SSIZE_T typedefs that trample on the
basetsd.h definitions of the same name and therefore need to match
exactly. Unlike size_t/ssize_t the uppercase ones always use unsigned
long (even on 32-bit).
This commit works around the build breakage by keeping the existing
definitions of uptr/sptr and just changing usize. A follow-up change
will attempt to fix this properly.
Fixes: https://github.com/llvm/llvm-project/issues/101998
Reviewed By: mstorsjo
Pull Request: https://github.com/llvm/llvm-project/pull/106151
(cherry picked from commit bb27dd853a713866c025a94ead8f03a1e25d1b6e)
fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535 broke the Solaris/sparcv9 buildbot:
```
compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:39:14: fatal error: 'asm/unistd.h' file not found
39 | # include <asm/unistd.h>
| ^~~~~~~~~~~~~~
```
That section should have been Linux-specific in the first place, which is
what this patch does.
Tested on sparcv9-sun-solaris2.11.
(cherry picked from commit 16e9bb9cd7f50ae2ec7f29a80bc3b95f528bfdbf)
The implementation of __arm_sc_memset in compiler-rt contains
a Neon dup instruction which is not valid in streaming mode. This
patch rewrites the function, using an SVE mov instruction if available.
(cherry picked from commit d6649f2d4871c4535ae0519920e36100748890c4)
```
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon/FileOps
```
`FAIL`s on 64-bit Linux/sparc64:
```
projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparcv9-Test --gtest_filter=SanitizerCommon.FileOps
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:144: Failure
Expected equality of these values:
len1 + len2
Which is: 10
fsize
Which is: 1721875535
```
The issue is similar to the mips64 case: the Linux/sparc64 `*stat`
syscalls take a `struct kernel_stat64 *` arg. Also the syscalls actually
used differ.
This patch handles this, adopting the mips64 code to avoid too much
duplication.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535)
```
SanitizerCommon-ubsan-sparc-Linux :: Linux/signal_send.cpp
```
currently `FAIL`s on Linux/sparc64 (32 and 64-bit). Instead of the
expected values for `SIGUSR1` (`10`) and `SIGUSR1` (`12`), that target
uses `30` and `31`.
On Linux/x86_64, the signals get their values from
`x86_64-linux-gnu/bits/signum-generic.h`, to be overridden in
`x86_64-linux-gnu/bits/signum.h`. On Linux/sparc64 OTOH, the definitions
are from `sparc64-linux-gnu/bits/signum-arch.h` and remain that way.
There's no `signum.h` at all.
The patch allows for both values.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 7cecbdfe4eac3fd7268532426fb6b13e51b8720d)
```
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest
```
and every single test using the `llvm-symbolizer` `FAIL` on
Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's
a call to `internal_fork`, but we never reach `internal_execve`.
`internal_fork` is implemented using `syscall(SYS_clone)`. The calling
convention of that syscall already varies considerably between targets,
but as documented in `clone(2)`, SPARC again is widely different.
Instead of trying to match `glibc` here, this patch just calls `__fork`.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 1c53b907bd6348138a59da270836fc9b4c161a07)
…sparc64
Two ioctl tests `FAIL` on Linux/sparc64 (both 32 and 64-bit):
```
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerIoctl/KVM_GET_LAPIC
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerIoctl/KVM_GET_MP_STATE
```
like
```
compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparc-Test --gtest_filter=SanitizerIoctl.KVM_GET_LAPIC
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_ioctl_test.cpp:91: Failure
Value of: res
Actual: false
Expected: true
compiler-rt/lib/sanitizer_common/tests/sanitizer_ioctl_test.cpp:92: Failure
Expected equality of these values:
ioctl_desc::WRITE
Which is: 2
desc.type
Which is: 1
```
The problem is that Linux/sparc64, like Linux/mips, uses a different
layout for the `ioctl` `request` arg than most other Linux targets as
can be seen in `sanitizer_platform_limits_posix.h` (`IOC_*`). Therefore,
this patch makes the tests use the correct one.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 9eefe065bb2752b0db9ed553d2406e9a15ce349e)
```
UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp
```
`FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the
test isn't Linux-specific at all). With
`UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a
duplicate innermost frame:
```
compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value
#0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38
```
which isn't seen with `fast_unwind_on_fatal=0`.
This turns out to be another fallout from fixing
`__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In
`sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the
`pc` arg is the return address, while `pc1` from the stack frame
(`fr_savpc`) is the address of the `call` insn, leading to a double
entry for the innermost frame in `trace_buffer[]`.
This patch fixes this by moving the adjustment before all uses.
Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`
(with the `ubsan/TestCases/Misc/Linux` tests enabled).
(cherry picked from commit 3368a3245ce5049b090d7c1081c2d52a6b6fda68)
In terms of bug catching capability, `_FORTIFY_SOURCE` does not perform
as well as some dynamic instrumentation tools. When a sanitizer is used,
generally `_FORTIFY_SOURCE` should be disabled since sanitizer runtime
does not implement most `*_chk` functions. Using `_FORTIFY_SOURCE`
will regress error checking (asan/hwasan/tsan) or cause false positives
(msan).
`*printf_chk` are the most pronounced `_chk` interceptors for
uninstrumented DSOes (https://reviews.llvm.org/D40951).
glibc 2.40 introduced `pass_object_info` style fortified source for some
functions ([1]). `fprintf` will be mangled as
`_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz`, which has no associated
interceptor, leading to printf-fortify-5.c failure.
Just disable the test. Fix#100877
[1]: https://sourceware.org/pipermail/libc-alpha/2024-February/154531.html
Pull Request: https://github.com/llvm/llvm-project/pull/101566
(cherry picked from commit bbdccf4c94ff18a0761b03a0e2c8b05805385132)
…parc64
```
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/InternalMmapWithOffset
```
`FAIL`s on 32-bit Linux/sparc64:
```
projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparc-Test --gtest_filter=SanitizerCommon.InternalMmapWithOffset
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:335: Failure
Expected equality of these values:
'A'
Which is: 'A' (65, 0x41)
p[0]
Which is: '\0'
```
It turns out the `pgoffset` arg to `mmap2` is passed incorrectly in this
case, unlike the 64-bit test. The caller, `MapWritableFileToMemory`,
passes an `u64` arg, while `mmap2` expects an `off_t`. This patch casts
the arg accordingly.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 1c25f2cd470c2882e422b66d0482f5a120960394)
```
SanitizerCommon-ubsan-sparc-Linux :: Linux/signal_line.cpp
```
currently `FAIL`s on Linux/sparc64 (32 and 64-bit) for `n == 2`. Instead
of the expected `SIGSEGV`, the test dies with `SIGBUS`. `strace` reveals
that this is due to a unaligned access:
```
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0x1} ---
```
which is to be expected on a strict-alignment target like SPARC. Fixed
by changing the invalid pointer to be better aligned.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 94394ca980f8ecbd845155d2170cfd865e4d62dc)
In 16e74fd48988a (for #82711) a duplicate definition of `IntPtrT` was
added to `InstrProfiling.h`, leading to warnings:
compiler-rt/lib/profile/InstrProfiling.h:52:15: warning: redefinition of typedef 'IntPtrT' is a C11 feature [-Wtypedef-redefinition]
52 | typedef void *IntPtrT;
| ^
compiler-rt/lib/profile/InstrProfiling.h:34:15: note: previous definition is here
34 | typedef void *IntPtrT;
| ^
Fix the warnings by removing the duplicate typedef.
(cherry picked from commit 2c376fe96c83443c15e6485d043ebe321904546b)
Since glibc 2.40 some functions like openat make use of overloads when
built with `-D_FORTIFY_SOURCE=2`, see:
https://github.com/bminor/glibc/blob/master/io/bits/fcntl2.h
This means that doing something like `(uintptr_t) openat` or `(void *)
openat` is now ambiguous, breaking the compiler-rt build on new glibc
versions.
Fix this by explicitly casting the symbol to the expected function type
before casting it to an intptr. The expected type is obtained as
`decltype(REAL(func))` so we don't have to repeat the signature from
INTERCEPTOR in the INTERCEPT_FUNTION macro.
Fixes https://github.com/llvm/llvm-project/issues/100754.
(cherry picked from commit 155b7a12820ec45095988b6aa6e057afaf2bc892)
Two allocator tests `FAIL` on Linux/sparc64:
```
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon/CombinedAllocator32Compact
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon/SizeClassAllocator32Iteration
```
The failure mode is the same on Solaris/sparcv9, where those tests are
already disabled since 0f69cbe2694a4740e6db5b99bd81a26746403072.
Therefore, this patch skips them on SPARC in general.
Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.
(cherry picked from commit 3d149123f46cee5ac8d961c6bf77c5c566f1e410)
Fixes a build failure on 19.1.0-rc1 when building on linux with musl as
the libc
musl does not provide mallopt, whereas glibc does. mallopt has
portability issues with other libc implementations. Just remove the use.
Co-authored-by: Daniel Martinez <danielmartinez@cock.li>
(cherry picked from commit 2c3eb8db057b9d58acd4735999f0f5d5d8d55b0d)
On FreeBSD amd64 (aka x86_64), registers are always defined as
`int64_t`, which in turn is equivalent to `long`. This leads to a number
of warnings in `DumpAllRegisters()`:
compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:2245:31: warning:
format specifies type 'unsigned long long' but the argument has type
'__register_t' (aka 'long') [-Wformat]
2245 | Printf("rax = 0x%016llx ", ucontext->uc_mcontext.mc_rax);
| ~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| %016lx
compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:2246:31: warning:
format specifies type 'unsigned long long' but the argument has type
'__register_t' (aka 'long') [-Wformat]
2246 | Printf("rbx = 0x%016llx ", ucontext->uc_mcontext.mc_rbx);
| ~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| %016lx
... more of these ...
Fix it by using the `lx` format.
(cherry picked from commit 62bd08acedc88d8976a017f7f6818f3167dfa697)
In a `runtimes` build on Solaris/amd64, there are two failues:
```
AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/failed_to_discover_tests_from_gtest
AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/failed_to_discover_tests_from_gtest
```
This happens when `lit` enumerates the tests with `--gtest_list_tests
--gtest_filter=-*DISABLED_*`. The error is twofold:
- The `LD_LIBRARY_PATH*` variables point at the 64-bit directory
(`lib/clang/19/lib/x86_64-pc-solaris2.11`) for a 32-bit test:
```
ld.so.1: Asan-i386-calls-Dynamic-Test: fatal:
/var/llvm/local-amd64-release-stage2-A-flang-clang18-runtimes/tools/clang/stage2-bins/./lib/../lib/clang/19/lib/x86_64-pc-solaris2.11/libclang_rt.asan.so:
wrong ELF class: ELFCLASS64
```
- While the tests are linked with `-Wl,-rpath`, that path always is the
64-bit directory again.
Accordingly, the fix consists of two parts:
- The code in `compiler-rt/test/asan/Unit/lit.site.cfg.py.in` to adjust
the `LD_LIBRARY_PATH*` variables is guarded by a `config.target_arch !=
config.host_arch` condition. This is wrong in two ways:
- The adjustment is always needed independent of the host arch. This is
what `compiler-rt/test/lit.common.cfg.py` already does.
- Besides, `config.host_arch` is ultimately set from
`CMAKE_HOST_SYSTEM_PROCESSOR`. On Linux/x86_64, this is `x86_64` (`uname
-m`) while on Solaris/amd64 it's `i386` (`uname -p`), explaining why the
transformation is skipped on Solaris, but not on Linux.
- Besides, `RPATH` needs to be set to the correct subdirectory, so
instead of using the default arch in `compiler-rt/CMakeLists.txt`, this
patch moves the code to a function which takes the test's arch into
account.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
(cherry picked from commit c34d673b02ead039acd107f096c1f32c16b61e07)
As detailed in Issue #100320, a considerable number of tests that
explicitly use `-fuse-ld=lld` `FAIL` on Linux/sparc64 due to several
`lld` limitations (no 32-bit SPARC support, lack of support for various
relocations, ...).
To reduce the noise, this patch disables `COMPILER_RT_HAS_LLD` on SPARC
wholesale.
Tested on `sparc64-unknown-linux-gnu`.
(cherry picked from commit 33a50e0eaa80cf3db1b944762db9a37a06f3ac32)
If the inline asm version of `ptrauth_strip` is used instead of the
builtin, the inline asm implementation currently returns an unsigned
long, causing an incompatible pointer conversion issue. The spec for
`ptrauth_sign` is that the result has the same type as the original
value, so we add a cast to the result of the inline asm.
(cherry picked from commit 25f9415713f9f57760a5322876906dc11385ef8e)
1. Include `ptrauth.h` if `ptrauth_intrinsics` language feature is specified (per ptrauth spec, this is what enables `ptrauh.h` usage and functions like `ptrauth_strip`)
2. For PAC-RET fallback implement two changes:
1. Switch to macro, so we can ignore key argument
2. Ensure the unsigned value is erased from LR, so the possibility of gadget reuse is reduced.
Fixes#100467
(cherry picked from commit cc4f98979b079b517edd8a71f56a8975f436e63d)
The documentation for the __arm_get_current_vg support routine specifies
that the following registers are call-preserved:
- X1-X15, X19-X29 and SP
- Z0-Z31
- P0-P15
This patch rewrites the implementation of this routine in compiler-rt,
as the current version does not guarantee that these registers will be
preserved.
(cherry picked from commit 6da6772bf0a33131aa8540c9d4f60d5db75c32b5)
vptr cannot be authenticated without knowing the class type if it was
signed with type discrimination.
Co-authored-by: Oliver Hunt <oliver@apple.com>
(cherry picked from commit 0a6a3c152faf56e07dd4f9e89e534d2b97eeab56)
Follows https://github.com/llvm/llvm-project/pull/98268 with a fix for a
segfault during preinit on `ubuntu:20.04` environments. Previously,
`rtsan` was not handling the situation where `dlsym` calls `calloc`
during the interceptors initialization, resulting in a call to a
function at a null address.
@cjappl and I took inspiration from the solution in `nsan`, but we
re-used the sanitizer internal allocator instead of our own static
buffer. This PR also re-enables the existing non-instrumented `rtsan`
tests for `x86_64` and `arm64` architectures.
---------
Co-authored-by: Chris Apple <cja-private@pm.me>
Before this change, when `file.profdata` have vtable profiles but `--enable-vtable-value-profiling` is not on for optimized build, warnings from this line [1] will show up. They are benign for performance but confusing.
It's better to automatically annotate vtable profiles if `file.profdata` has them. This PR implements it in profile use pass.
* If `-icp-max-num-vtables` is zero (default value is 6), vtable profiles won't be annotated.
[1] 464d321ee8/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp (L1762-L1768)
A number of streaming-compatible versions of standard C functions
were added to compiler-rt, however there are already optimised
versions of most of these in libc which are valid in streaming-SVE
mode. This patch replaces the implementations of __arm_sc_mem* with
these versions where possible.
Base on https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74, this
patch defines the `__riscv_feature_bits` and
`__riscv_vendor_feature_bits` structures to store the enabled feature
bits at runtime.
It also introduces the `__init_riscv_feature_bits` function to update
these structures based on the platform query mechanism.
Additionally, the groupid/bitmask definitions from
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74 are declared
and used to update the `__riscv_feature_bits` and
`__riscv_vendor_feature_bits` structures.
---------
Co-authored-by: Kito Cheng <kito.cheng@gmail.com>
This addresses the spurious inclusion of (now unsupported) target
features '-3dnow' and '-3dnowa' when disabling mmx (when then caused log
output from `clang -mno-mmx`).
It should've been part of PR #96246, but was missed.
Also tweaks the warning in prfchwintrin.h to not recommend the
deprecated mm3dnow.h header.
