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
This patch implements the implicit truncation and implicit sign change
checks for bitfields using UBSan. E.g.,
`-fsanitize=implicit-bitfield-truncation` and
`-fsanitize=implicit-bitfield-sign-change`.
Clean-up all of the calls and remove the redundant == 0 checks.
There is only one small visible change. For non-Android, the memalign
function will now fail if alignment is zero. Before this would have
passed.
`Linux/instrprof-vtable-value-prof.cpp` needs to be built for the test
to run. However, cpp compile & link failed with undefined-ABI error [1].
See original failure in
https://lab.llvm.org/buildbot/#/builders/18/builds/16429
[1]
```
FAIL: Profile-powerpc64 :: Linux/instrprof-vtable-value-prof.cpp (2406 of 2414)
******************** TEST 'Profile-powerpc64 :: Linux/instrprof-vtable-value-prof.cpp' FAILED ********************
Exit Code: 1
Command Output (stderr):
--
RUN: at line 3: /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/build_debug/./bin/clang --driver-mode=g++ -m64 -ldl -fprofile-generate -fuse-ld=lld -O2 -g -fprofile-generate=. -mllvm -enable-vtable-value-profiling /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/llvm-project/compiler-rt/test/profile/Linux/instrprof-vtable-value-prof.cpp -o /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/build_debug/runtimes/runtimes-bins/compiler-rt/test/profile/Profile-powerpc64/Linux/Output/instrprof-vtable-value-prof.cpp.tmp-test
+ /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/build_debug/./bin/clang --driver-mode=g++ -m64 -ldl -fprofile-generate -fuse-ld=lld -O2 -g -fprofile-generate=. -mllvm -enable-vtable-value-profiling /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/llvm-project/compiler-rt/test/profile/Linux/instrprof-vtable-value-prof.cpp -o /home/buildbots/llvm-external-buildbots/workers/ppc64be-sanitizer/sanitizer-ppc64be/build/build_debug/runtimes/runtimes-bins/compiler-rt/test/profile/Profile-powerpc64/Linux/Output/instrprof-vtable-value-prof.cpp.tmp-test
ld.lld: error: /lib/../lib64/Scrt1.o: ABI version 1 is not supported
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
(The profile format change is split into a standalone change into https://github.com/llvm/llvm-project/pull/81691)
* For InstrFDO value profiling, implement instrumentation and lowering for virtual table address.
* This is controlled by `-enable-vtable-value-profiling` and off by default.
* When the option is on, raw profiles will carry serialized `VTableProfData` structs and compressed vtables as payloads.
* Implement profile reader and writer support
* Raw profile reader is used by `llvm-profdata` but not compiler. Raw profile reader will construct InstrProfSymtab with symbol names, and map profiled runtime address to vtable symbols.
* Indexed profile reader is used by `llvm-profdata` and compiler. When initialized, the reader stores a pointer to the beginning of in-memory compressed vtable names and the length of string. When used in `llvm-profdata`, reader decompress the string to show symbols of a profiled site. When used in compiler, string decompression doesn't
happen since IR is used to construct InstrProfSymtab.
* Indexed profile writer collects the list of vtable names, and stores that to index profiles.
* Text profile reader and writer support are added but mostly follow the implementation for indirect-call value type.
* `llvm-profdata show -show-vtables <args> <profile>` is implemented.
rfc in
https://discourse.llvm.org/t/rfc-dynamic-type-profiling-and-optimizations-in-llvm/74600#pick-instrumentation-points-and-instrument-runtime-types-7
This fixes a nit I had accidentally introduced in
https://github.com/llvm/llvm-project/pull/85142
I don't think the value of __msan_get_track_origins() will change
between the start and end of InitShadowWithReExec, but it's cleaner to
use the parameter.
This reverts commit d2b63ed0ca5c7eb3f8fc029e3a5705cf0ddab438. CI again.
Leading theory is bad interaction between cmake and buildbot, some guesses at PR86737
It appears that qemu does not actually cause mmap to fail when calling
setrlimit to limit the address space size. In the two tests that use
setrlimit, detect if mmap still works and skip the tests in that case.
Since all Android targets should support setrlimit, compile out the mmap
check code for them.
Only attempt to initialize the ring buffer when tracking is enabled.
Updated unit tests, and added a few new unit tests to verify the
RingBuffer is not initialized by default.
Verified that the two maps associated with the RingBuffer are not
created in processes by default.
In the StackDepot::isValid function, there is work to validate the
TabMask variable. Unfortunately, if TabMask is set to the maximum
allowed value, TabSize = TabMask + 1 becomes zero and validation passes.
Disallow that case to prevent invalid reads into the Tab structure.
This makes it so we'll be able to decode the instructions used in the
weak function stubs from
https://github.com/llvm/llvm-project/pull/81677. This code doesn't
technically require those changes.
Co-authored-by: Amy Wishnousky <amyw@microsoft.com>
I introduced this test in #86537, let's remove some unneeded debugging
comments.
This PR was initially also moving the test to linux directory but looks
like it's already done by 17ab9e64464f989b3fe4a304a450581a618097a0 .
