These flags are not needed for building libc.
Summary: These were originally intended to represent the functions that are present on the GPU as to be provided by the LLVM libc implementation. The original plan was that LLVM libc would report which functions were supported and then the offload interface would mark those as supported. The problem is that these wrapper headers are very difficult to make work given the various libc extensions everyone does so they were extremely fragile. OpenMP already declares all functions used inside of a target region as implicitly host / device, while these headers weren't even used for CUDA / HIP yet anyway. The only things we need to define right now are the stdio FILE types. If we want to make this work for CUDA we'd need to define these manually, but we're a ways off and that's way easier because they do proper overloading.
Currently there are no 32 bit presubmit builds for libc. This PR performs 32 bit build only (no test) to check any changes that land in libc break 32 bit builds. Co-authored-by: Aiden Grossman <aidengrossman@google.com>
Reverts llvm/llvm-project#166355
_Exit(3) is a fairly simple syscall wrapper whereas exit(3) calls atexit-registered functions + whole lot of stuff that require support for sync primitives. Splitting the tests allows testing the former easily (especially for new port projects) --------- Signed-off-by: Shreeyash Pandey <shreeyash335@gmail.com>
When the backend for the host target isn't enabled, Clang would report the default target as `unknown`. This currently breaks the libc CMake build, but shouldn't in the case where we're cross-compiling since we're given an explicit target and the default one isn't being used.
Add in SVE/SVE2/MOPS features for aarch64 cpus. These features may be interesting for future memory/math routines. SVE/SVE2 are now being accepted in more implementations: ``` ❯ echo | clang-21 -dM -E - -march=native | grep -i ARM_FEAT #define __ARM_FEATURE_ATOMICS 1 #define __ARM_FEATURE_BF16 1 #define __ARM_FEATURE_BF16_SCALAR_ARITHMETIC 1 #define __ARM_FEATURE_BF16_VECTOR_ARITHMETIC 1 #define __ARM_FEATURE_BTI 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_FEATURE_COMPLEX 1 #define __ARM_FEATURE_CRC32 1 #define __ARM_FEATURE_DIRECTED_ROUNDING 1 #define __ARM_FEATURE_DIV 1 #define __ARM_FEATURE_DOTPROD 1 #define __ARM_FEATURE_FMA 1 #define __ARM_FEATURE_FP16_SCALAR_ARITHMETIC 1 #define __ARM_FEATURE_FP16_VECTOR_ARITHMETIC 1 #define __ARM_FEATURE_FRINT 1 #define __ARM_FEATURE_IDIV 1 #define __ARM_FEATURE_JCVT 1 #define __ARM_FEATURE_LDREX 0xF #define __ARM_FEATURE_MATMUL_INT8 1 #define __ARM_FEATURE_NUMERIC_MAXMIN 1 #define __ARM_FEATURE_PAUTH 1 #define __ARM_FEATURE_QRDMX 1 #define __ARM_FEATURE_RCPC 1 #define __ARM_FEATURE_SVE 1 #define __ARM_FEATURE_SVE2 1 #define __ARM_FEATURE_SVE_BF16 1 #define __ARM_FEATURE_SVE_MATMUL_INT8 1 #define __ARM_FEATURE_SVE_VECTOR_OPERATORS 2 #define __ARM_FEATURE_UNALIGNED 1 ``` MOPS is another set of extension for string operations, but may not be generally available for now: ``` ❯ echo | clang-21 -dM -E - -march=armv9.2a+mops | grep -i MOPS #define __ARM_FEATURE_MOPS 1 ```
This options sets a compile option when building sources inside the string directory, and this option affects string_utils.h. But string_utils.h is #included from more places than just the string directory (such as from __support/CPP/string.h), leading to both narrow-reads in those cases, but more seriously, ODR violations when the two different string_length implementations are included int he same program. Having this option at the top level avoids this problem.
Reverts llvm/llvm-project#160413
Relates to https://github.com/llvm/llvm-project/issues/119281 Note: 1) As this PR enables `-Werror` for `libc` tests, it's very likely some downstream CI's may fail / start failing, so it's very likely this PR may need to be reverted and re-applied. P.S. I do not have merge permissions, so I will need one of the reviews to merge it for me. Thank you!