`Region->Exhausted` indicates that we don't have more pages to create
new blocks in the region. It has different meaning from region
allocation failure.
Also fix a minor lint in popBlocks()
Previously, the memprof and ctx_profile lit.site.cfg would assert
if the enable_per_target_runtime_dir was set and the
config.target_arch != config.host_arch. However, config.host_arch would
never be set, meaning this would always fail in a when using
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR.
This patch follows the example in the ASAN lit.site.cfg.py that updates
the compiler_rt_libdir appropriately.
When compiling the common sanitizer libraries, there are many warnings
about format specifiers, similar to:
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:31:32: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat]
31 | buffer->AppendF(kFormatData, DI->start);
| ~~~~~~~~~~~ ^~~~~~~~~
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:33:46: note: format string is defined here
33 | constexpr const char *kFormatData = "{{{data:%p}}}";
| ^~
| %lu
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:46:43: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat]
46 | buffer->AppendF(kFormatFrame, frame_no, address);
| ~~~~~~~~~~~~ ^~~~~~~
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:36:48: note: format string is defined here
36 | constexpr const char *kFormatFrame = "{{{bt:%u:%p}}}";
| ^~
| %lu
...
This is because `uptr` is dependent on the platform, and can be either
`unsigned long long`, `unsigned long`, or `unsigned int`.
To fix the warnings, cast the arguments to the expected type of the
format strings.
Trying to address the build failure on the `clang-ve-ninja`bot, which
appears hard to repro locally. The target isn't needed currently (there
are unit tests exercising the new functionality). Removing it for now
to green-ify the build bot.
Currently, `check-gwp_asan` is added no matter its dependencies are
built or not, this is wrong and will cause cmake error when scudo is not
built. This patch includes the target in the dependencies check.
Downstream disabled EnableContiguousRegions on RISCV-64 to avoid
running out of virtual memory, but our tests still use the internal
FuchsiaConfig class, which therefore needs to be changed too.
If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.
Let's also place libclang_rt into lib/<normalized_triple>.
`libcxx/utils/ci/run-buildbot` is also updated to use
`armv7m-none-unknown-eabi` as normalized triple instead of
current `armv7m-none-eabi`.
ChangeLog of this PR:
This patch has been applied and revert twice:
1. The first try is https://github.com/llvm/llvm-project/pull/88407, and
then it is found that it causes some CI failures.
https://lab.llvm.org/buildbot/#/builders/98/builds/36366
It is then resolved by another commit:
1693009679https://lab.llvm.org/buildbot/#/builders/77/builds/36372
It is caused that `COMPILER_RT_DEFAULT_TARGET_TRIPLE` is overwrite
without taking care about `CACHE`.
2. The second try https://github.com/llvm/llvm-project/pull/88835,
resolves https://lab.llvm.org/buildbot/#/builders/77/builds/36372
and in fact only one `execute_process` is needed.
Then we find some other CI failures.
https://github.com/mstorsjo/llvm-mingw/actions/runs/8730621159https://buildkite.com/llvm-project/libcxx-ci/builds/34897#018eec06-612c-47f1-9931-d3bd88bf7ced
It is due to misunderstanding `-print-effective-triple`: which will
output `thumbv7-w64-windows-gnu` for `armv7-w64-windows-gnu` or some
other thumb-enabled arm triples.
In fact we should use `-print-target-triple`.
For armv7m-picolibc, `armv7m-none-eabi` is hardcoded in
libcxx/utils/ci/run-buildbot, while in fact `armv7m-none-unknown-eabi`
is the real normalized triple.
This reverts commit 16f188761da1df6ba5e6627b8742aacfec8e9ec5.
This broke Libcxx Picolib testing at the install step, and builds
for Windows builtins. Revert while we figure out the cause.
Reverts llvm/llvm-project#88965
This caused a test suite failure:
https://lab.llvm.org/buildbot/#/builders/185/builds/6583
NOEXE: test-suite::aarch64-acle-fmv-features.test
```
/home/tcwg-buildbot/worker/clang-aarch64-lld-2stage/test/test-suite/SingleSource/UnitTests/AArch64/acle-fmv-features.c:98:1: error: redefinition of 'check_sha1'
98 | CHECK(sha1, {
| ^
/home/tcwg-buildbot/worker/clang-aarch64-lld-2stage/test/test-suite/SingleSource/UnitTests/AArch64/acle-fmv-features.c:36:17: note: expanded from macro 'CHECK'
36 | static void check_##X(void) { \
| ^
<scratch space>:150:1: note: expanded from here
150 | check_sha1
| ^
```
I presume that the useless features need to be removed from the fmv test
as well.
As explained in https://github.com/ARM-software/acle/pull/315 we
are deprecating features which aren't adding any value. These are:
sha1, pmull, dit, dgh, ebf16, sve-bf16, sve-ebf16, sve-i8mm,
sve2-pmull128, memtag2, memtag3, ssbs2, bti, ls64_v, ls64_accdata
The code in this file dates back to 2012 when Clang's support for atomic
builtins was still quite limited. The bugs referenced in the comment
at the top of the file have long been fixed and using the compiler
builtins directly should now generate slightly better code.
Additionally, this allows using the atomic builtin header for platforms
where the __sync_builtins are lacking (e.g. Arm Morello).
This change does not introduce any code generation changes for
__tsan_read*/__tsan_write* or __tsan_func_{entry,exit} on x86, which
indicates the previously noted compiler issues have been fixed.
We also have to touch the non-clang codepaths here since the only way we
can make this work easily is by making the memory_order enum match the
compiler-provided macros, so we have to update the debug checks that
assumed the enum was always a bitflag.
The one downside of this change is that 32-bit MIPS now definitely
requires libatomic (but that may already have been needed for RMW ops).
Reviewed By: dvyukov
Pull Request: https://github.com/llvm/llvm-project/pull/84439
If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.
Let's also place libclang_rt into lib/<normalized_triple>.
If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, and the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.
Let's also place libclang_rt into lib/<normalized_triple>.
Currently, the testsuite uses the default runtimes path to find the
runtimes libraries which may or may not match the just-built runtimes.
This change uses the `-resource-dir` flag for clang whenever
`COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` is set to ensure that we are
actually testing the currently built libraries rather than the ones
bundled with `${COMPILER_RT_TEST_COMPILER}`.
The existing logic works fine when clang and compiler-rt share the same
build directory ``-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`, but when
building compiler-rt separately we need to tell the compiler used for
the tests where it can find the just-built libraries.
This reduces the fixes check-all failures to one in my configuration:
```
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G Ninja
-DCMAKE_C_COMPILER=$HOME/output/upstream-llvm/bin/clang
-DCMAKE_CXX_COMPILER=$HOME/output/upstream-llvm/bin/clang++
-DCOMPILER_RT_INCLUDE_TESTS=ON
-DLLVM_EXTERNAL_LIT=$HOME/build/upstream-llvm-project-build/bin/llvm-lit
-DLLVM_CMAKE_DIR=$HOME/output/upstream-llvm
-DCOMPILER_RT_DEBUG=OFF
-S $HOME/src/upstream-llvm-project/compiler-rt
-B $HOME/src/upstream-llvm-project/compiler-rt/cmake-build-all-sanitizers
```
This relands the previous PR with fixes for Windows.
Depends on https://github.com/llvm/llvm-project/pull/88074 to be merged
first for GCC buildbots.
Pull Request: https://github.com/llvm/llvm-project/pull/88075
`__xray_customevent` and `__xray_typedevent` are built-in functions in
Clang. With -fxray-instrument, they are lowered to `__xray_CustomEvent`
(with 2 arguments) or `__xray_TypedEvent` (with 3 arguments).
xray patching is supported for shared objects, but they may contain
`__xray_customevent` and `__xray_typedevent` references that need to be
satisfied by default visibility definitions exported by the executable.
lld since df54f627fad789ccb11c72a9fddf116decbeba0e, like GNU ld, catches
the scenario at link time.
Apple's new linker reports itself as ld rather than ld64 and does not
match the version detection regex.
Invert the logic to look only for older versions of ld64. This ensures
the runtime dylibs are left with a linker-generated code signature that
tools such as `strip` will preserve.
Co-authored-by: Mark Rowe <markrowe@chromium.org>
This fixes https://github.com/llvm/llvm-project/issues/87324.
We haven't been able to come up with a minimal reproducer but we can
reliabely avoid this failure with the following fix. Prior to the
GetGlobalLowLevelAllocator change, the old LowLevelAllocator aquired a
lock associated with it preventing that specific allocator from being
accessed at the same time by many threads. With the
GetGlobalLowLevelAllocator change, I had accidentally replaced it but
not taken into account the lock, so we can have a data race if the
allocator is used at any point while a thread is being created. The
global allocator can be used for flag parsing or registering asan
globals.
This releases the requirement that we need to preserve the memory for
all regions at the beginning. It needs a huge amount of contiguous pages
and which may be a challenge in certain cases. Therefore, adding a new
flag, EnableContiguousRegions, to indicate whether we want to allocate
all the regions next to each other.
Note that once the EnableContiguousRegions is disabled,
EnableRandomOffset becomes irrelevant because the base of each region is
already random.
Unlike the other compiler-rt unit tests MemProf was not using the
`generate_compiler_rt_tests()` helper that ensures the test is compiled
using the test compiler (generally the Clang binary built earlier).
This was exposed by https://github.com/llvm/llvm-project/pull/83088
because it started adding Clang-specific flags to
COMPILER_RT_UNITTEST_CFLAGS if the compiler ID matched "Clang".
This change should fix the buildbots that compile compiler-rt using
a GCC compiler with LLVM_ENABLE_PROJECTS=compiler-rt.
Reviewed By: vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/88074
As discussed here:
https://github.com/llvm/llvm-project/pull/74394#issuecomment-2035264683
An unintentional change of behavior was introduced in #74394
This code introduced in #74394 :
The first time through
* SANITIZER_MIN_OSX_VERSION is not set
* parse -mmacosx-version-min and set MACOSX_VERSION_MIN_FLAG
* Set and cache SANITIZER_MIN_OSX_VERSION
Subsequent times through:
* SANITIZER_MIN_OSX_VERSION is cached
* (BUG!!) you don't parse -mmacosx-version-min, and don't set
MACOSX_VERSION_MIN_FLAG
MACOSX_VERSION_MIN_FLAG is used later in the file on this line:
63c925ca80/compiler-rt/cmake/config-ix.cmake (L517)
Hoisting this assignment outside the if block returns us to the previous
behavior before this commit, while maintaining the flexibility
introduced with the cache variable
Fix since #75481 got reverted.
- Explicitly set BitfieldBits to 0 to avoid uninitialized field member
for the integer checks:
```diff
- llvm::ConstantInt::get(Builder.getInt8Ty(), Check.first)};
+ llvm::ConstantInt::get(Builder.getInt8Ty(), Check.first),
+ llvm::ConstantInt::get(Builder.getInt32Ty(), 0)};
```
- `Value **Previous` was erroneously `Value *Previous` in
`CodeGenFunction::EmitWithOriginalRHSBitfieldAssignment`, fixed now.
- Update following:
```diff
- if (Kind == CK_IntegralCast) {
+ if (Kind == CK_IntegralCast || Kind == CK_LValueToRValue) {
```
CK_LValueToRValue when going from, e.g., char to char, and
CK_IntegralCast otherwise.
- Make sure that `Value *Previous = nullptr;` is initialized (see
1189e87951)
- Add another extensive testcase
`ubsan/TestCases/ImplicitConversion/bitfield-conversion.c`
---------
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
Currently, the testsuite uses the default runtimes path to find the
runtimes libraries which may or may not match the just-built runtimes.
This change uses the `-resource-dir` flag for clang whenever
`COMPILER_RT_TEST_STANDALONE_BUILD_LIBS` is set to ensure that we are
actually testing the currently built libraries rather than the ones
bundled with `${COMPILER_RT_TEST_COMPILER}`.
The existing logic works fine when clang and compiler-rt share the same
build directory ``-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`, but when
building compiler-rt separately we need to tell the compiler used for
the tests where it can find the just-built libraries.
This reduces the fixes check-all failures to one in my configuration:
```
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G Ninja
-DCMAKE_C_COMPILER=$HOME/output/upstream-llvm/bin/clang
-DCMAKE_CXX_COMPILER=$HOME/output/upstream-llvm/bin/clang++
-DCOMPILER_RT_INCLUDE_TESTS=ON
-DLLVM_EXTERNAL_LIT=$HOME/build/upstream-llvm-project-build/bin/llvm-lit
-DLLVM_CMAKE_DIR=$HOME/output/upstream-llvm
-DCOMPILER_RT_DEBUG=OFF
-S $HOME/src/upstream-llvm-project/compiler-rt
-B $HOME/src/upstream-llvm-project/compiler-rt/cmake-build-all-sanitizers
```
Reviewed By: vitalybuka, delcypher, MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/83088
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the libfuzzer tests. This allows a clang built on a machine with a
new linker to run compiler-rt tests on a machine with an old linker.
rdar://125932376
