SX Aurora VE is an experimental target. We upstreamed many part of
ported llvm and clang. In order to continue this move, we need to
support libraries next, then we need to show the ability of llvm for
VE through test cases. As a first step for that, we need to use
crt in compiler-rt. VE has it's own crt but they are a part of
proprietary compiler. So, we want to use crt in compiler-rt as an
alternative.
This patch enables VE as a candidate of crt in compiler-rt.
Reviewed By: phosek, compnerd
Differential Revision: https://reviews.llvm.org/D92748
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are replaced
with the more appropriate `#if SANITIZER_GLIBC` (the headers are glibc
extensions, not specific to Linux (i.e. if we ever support GNU/kFreeBSD
or Hurd, the guards may automatically work)).
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are refined
with `#if SANITIZER_GLIBC` (the definitions are available on Linux glibc,
but may not be available on other libc (e.g. musl) implementations).
This patch makes `ninja asan cfi lsan msan stats tsan ubsan xray` build on a musl based Linux distribution (apk install musl-libintl)
Notes about disabled interceptors for musl:
* `SANITIZER_INTERCEPT_GLOB`: musl does not implement `GLOB_ALTDIRFUNC` (GNU extension)
* Some ioctl structs and functions operating on them.
* `SANITIZER_INTERCEPT___PRINTF_CHK`: `_FORTIFY_SOURCE` functions are GNU extension
* `SANITIZER_INTERCEPT___STRNDUP`: `dlsym(RTLD_NEXT, "__strndup")` errors so a diagnostic is formed. The diagnostic uses `write` which hasn't been intercepted => SIGSEGV
* `SANITIZER_INTERCEPT_*64`: the `_LARGEFILE64_SOURCE` functions are glibc specific. musl does something like `#define pread64 pread`
* Disabled `msg_iovlen msg_controllen cmsg_len` checks: musl is conforming while many implementations (Linux/FreeBSD/NetBSD/Solaris) are non-conforming. Since we pick the glibc definition, exclude the checks for musl (incompatible sizes but compatible offsets)
Pass through LIBCXX_HAS_MUSL_LIBC to make check-msan/check-tsan able to build libc++ (https://bugs.llvm.org/show_bug.cgi?id=48618).
Many sanitizer features are available now.
```
% ninja check-asan
(known issues:
* ASAN_OPTIONS=fast_unwind_on_malloc=0 odr-violations hangs
)
...
Testing Time: 53.69s
Unsupported : 185
Passed : 512
Expectedly Failed: 1
Failed : 12
% ninja check-ubsan check-ubsan-minimal check-memprof # all passed
% ninja check-cfi
( all cross-dso/)
...
Testing Time: 8.68s
Unsupported : 264
Passed : 80
Expectedly Failed: 8
Failed : 32
% ninja check-lsan
(With GetTls (D93972), 10 failures)
Testing Time: 4.09s
Unsupported: 7
Passed : 65
Failed : 22
% ninja check-msan
(Many are due to functions not marked unsupported.)
Testing Time: 23.09s
Unsupported : 6
Passed : 764
Expectedly Failed: 2
Failed : 58
% ninja check-tsan
Testing Time: 23.21s
Unsupported : 86
Passed : 295
Expectedly Failed: 1
Failed : 25
```
Used `ASAN_OPTIONS=verbosity=2` to verify there is no unneeded interceptor.
Partly based on Jari Ronkainen's https://reviews.llvm.org/D63785#1921014
Note: we need to place `_FILE_OFFSET_BITS` above `#include "sanitizer_platform.h"` to avoid `#define __USE_FILE_OFFSET64 1` in 32-bit ARM `features.h`
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D93848
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are replaced
with the more appropriate `#if SANITIZER_GLIBC` (the headers are glibc
extensions, not specific to Linux (i.e. if we ever support GNU/kFreeBSD
or Hurd, the guards may automatically work)).
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are refined
with `#if SANITIZER_GLIBC` (the definitions are available on Linux glibc,
but may not be available on other libc (e.g. musl) implementations).
This patch makes `ninja asan cfi msan stats tsan ubsan xray` build on a musl based Linux distribution (apk install musl-libintl)
Notes about disabled interceptors for musl:
* `SANITIZER_INTERCEPT_GLOB`: musl does not implement `GLOB_ALTDIRFUNC` (GNU extension)
* Some ioctl structs and functions operating on them.
* `SANITIZER_INTERCEPT___PRINTF_CHK`: `_FORTIFY_SOURCE` functions are GNU extension
* `SANITIZER_INTERCEPT___STRNDUP`: `dlsym(RTLD_NEXT, "__strndup")` errors so a diagnostic is formed. The diagnostic uses `write` which hasn't been intercepted => SIGSEGV
* `SANITIZER_INTERCEPT_*64`: the `_LARGEFILE64_SOURCE` functions are glibc specific. musl does something like `#define pread64 pread`
* Disabled `msg_iovlen msg_controllen cmsg_len` checks: musl is conforming while many implementations (Linux/FreeBSD/NetBSD/Solaris) are non-conforming. Since we pick the glibc definition, exclude the checks for musl (incompatible sizes but compatible offsets)
Pass through LIBCXX_HAS_MUSL_LIBC to make check-msan/check-tsan able to build libc++ (https://bugs.llvm.org/show_bug.cgi?id=48618).
Many sanitizer features are available now.
```
% ninja check-asan
(known issues:
* ASAN_OPTIONS=fast_unwind_on_malloc=0 odr-violations hangs
)
...
Testing Time: 53.69s
Unsupported : 185
Passed : 512
Expectedly Failed: 1
Failed : 12
% ninja check-ubsan check-ubsan-minimal check-memprof # all passed
% ninja check-cfi
( all cross-dso/)
...
Testing Time: 8.68s
Unsupported : 264
Passed : 80
Expectedly Failed: 8
Failed : 32
% ninja check-lsan
(With GetTls (D93972), 10 failures)
Testing Time: 4.09s
Unsupported: 7
Passed : 65
Failed : 22
% ninja check-msan
(Many are due to functions not marked unsupported.)
Testing Time: 23.09s
Unsupported : 6
Passed : 764
Expectedly Failed: 2
Failed : 58
% ninja check-tsan
Testing Time: 23.21s
Unsupported : 86
Passed : 295
Expectedly Failed: 1
Failed : 25
```
Used `ASAN_OPTIONS=verbosity=2` to verify there is no unneeded interceptor.
Partly based on Jari Ronkainen's https://reviews.llvm.org/D63785#1921014
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D93848
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are replaced
with the more appropriate `#if SANITIZER_GLIBC` (the headers are glibc
extensions, not specific to Linux (i.e. if we ever support GNU/kFreeBSD
or Hurd, the guards may automatically work)).
Several `#if SANITIZER_LINUX && !SANITIZER_ANDROID` guards are refined
with `#if SANITIZER_GLIBC` (the definitions are available on Linux glibc,
but may not be available on other libc (e.g. musl) implementations).
This patch makes `ninja asan cfi msan stats tsan ubsan xray` build on a musl based Linux distribution (apk install musl-libintl)
Notes about disabled interceptors for musl:
* `SANITIZER_INTERCEPT_GLOB`: musl does not implement `GLOB_ALTDIRFUNC` (GNU extension)
* Some ioctl structs and functions operating on them.
* `SANITIZER_INTERCEPT___PRINTF_CHK`: `_FORTIFY_SOURCE` functions are GNU extension
* `SANITIZER_INTERCEPT___STRNDUP`: `dlsym(RTLD_NEXT, "__strndup")` errors so a diagnostic is formed. The diagnostic uses `write` which hasn't been intercepted => SIGSEGV
* `SANITIZER_INTERCEPT_*64`: the `_LARGEFILE64_SOURCE` functions are glibc specific. musl does something like `#define pread64 pread`
* Disabled `msg_iovlen msg_controllen cmsg_len` checks: musl is conforming while many implementations (Linux/FreeBSD/NetBSD/Solaris) are non-conforming. Since we pick the glibc definition, exclude the checks for musl (incompatible sizes but compatible offsets)
Pass through LIBCXX_HAS_MUSL_LIBC to make check-msan/check-tsan able to build libc++ (https://bugs.llvm.org/show_bug.cgi?id=48618).
Many sanitizer features are available now.
```
% ninja check-asan
(known issues:
* ASAN_OPTIONS=fast_unwind_on_malloc=0 odr-violations hangs
)
...
Testing Time: 53.69s
Unsupported : 185
Passed : 512
Expectedly Failed: 1
Failed : 12
% ninja check-ubsan check-ubsan-minimal check-memprof # all passed
% ninja check-cfi
( all cross-dso/)
...
Testing Time: 8.68s
Unsupported : 264
Passed : 80
Expectedly Failed: 8
Failed : 32
% ninja check-msan
(Many are due to functions not marked unsupported.)
Testing Time: 23.09s
Unsupported : 6
Passed : 764
Expectedly Failed: 2
Failed : 58
% ninja check-tsan
Testing Time: 23.21s
Unsupported : 86
Passed : 295
Expectedly Failed: 1
Failed : 25
```
Used `ASAN_OPTIONS=verbosity=2` to verify no unneeded interceptors.
Partly based on Jari Ronkainen's https://reviews.llvm.org/D63785#1921014
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D93848
aa772fc85e (D92530) has landed fixing relocations on Darwin.
3000c19df6 (D93236) has landed working around an assembly parser bug on Darwin.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93278
aa772fc85e (D92530) has landed fixing Apple builds.
Previous quick-fix d9697c2e6b (D93198) included in this commit.
Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.
Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.
Fixes https://llvm.org/PR48494
Differential Revision: https://reviews.llvm.org/D93211
On AArch64 it allows use the native FP16 ABI (although libcalls are
not emitted for fptrunc/fpext lowering), while on other architectures
the expected current semantic is preserved (arm for instance).
For testing the _Float16 usage is enabled by architecture base,
currently only for arm, aarch64, and arm64.
This re-enabled revert done by https://reviews.llvm.org/rGb534beabeed3ba1777cd0ff9ce552d077e496726
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D92241
Revert "[compiler-rt] [builtins] Support conversion between fp16 and fp128" & dependency
Revert "[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available"
This reverts commit 7a94829881.
This reverts commit 1fb91fcf9c.
This patch adds both extendhftf2 and trunctfhf2 to support
conversion between half-precision and quad-precision floating-point
values. They are enabled iff the compiler supports _Float16.
Some notes on ARM plaforms: while __fp16 is supported on all
architectures, _Float16 is supported only for 32-bit ARM, 64-bit ARM,
and SPIR (as indicated by clang/docs/LanguageExtensions.rst). Also,
__fp16 is a storage format and promoted to 'float' for argument passing
and 64-bit ARM supports floating-point convert precision to half as
base armv8-a instruction.
It means that although extendhfsf2, truncdfhf2 __truncsfhf2 will be
built for 64-bit ARM, they will be never used in practice (compiler
won't emit libcall to them). This patch does not change the ABI for
32-bit ARM, it will continue to pass _Float16 as uint16.
Differential Revision: https://reviews.llvm.org/D91732
CMake's find_package(Python3) and find_package(Python2) packages have a PYTHON_EXECUTABLE, Python2_EXECUTABLE, and Python3_EXECUTABLE cmake variables which control which version of python is built against. As far as I can tell, the rest of LLVM honors these variables. This can cause the build process to fail when if the automatically selected version of Python can't run due to modifications of LD_LIBRARY_PATH when using spack. The corresponding Spack issue is https://github.com/spack/spack/issues/19908. The corresponding LLVM issue is 48180
I believe an appropriate fix is to add the variables to the list of PASSTHROUGH_VARIABLES in cmake/Modules/AddCompilerRT.cmake, and this fixed compilation errors for me.
This bug affects distributions like Gentoo and package managers like Spack which allow for combinatorial versioning.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D91536
Reland: a2291a58bf.
New fixes for the breakages reported in D85927 include:
- declare a weak decl for `dl_iterate_phdr`, because it does not exist on older APIs
- Do not enable leak-sanitizer if api_level is less than 29, because of `ld.lld: error: undefined symbol: __aeabi_read_tp` for armv7, API level 16.
- Put back the interceptor for `memalign` but still opt out intercepting `__libc_memalign` and `cfree` because both of these don't exist in Bionic.
Reviewed By: srhines, vitalybuka
Differential Revision: https://reviews.llvm.org/D89251
This patch adds support for building the compiler-rt profile library on AIX.
Reviewed by: phosek
Differential Revision: https://reviews.llvm.org/D90619
- Fixing VS compiler and other cases settings this time.
Reviewers: dmajor, hans
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D89759
Revert "Fix compiler-rt build on Windows after D89640"
This reverts commit a7acee89d6.
This reverts commit d09b08919c.
Reason: breaks Linux / x86_64 build.
See RFC for background:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html
Follow on companion to the clang/llvm instrumentation support in D85948
and committed earlier.
This patch adds the compiler-rt runtime support for the memory
profiling.
Note that much of this support was cloned from asan (and then greatly
simplified and renamed). For example the interactions with the
sanitizer_common allocators, error handling, interception, etc.
The bulk of the memory profiling specific code can be found in the
MemInfoBlock, MemInfoBlockCache, and related classes defined and used
in memprof_allocator.cpp.
For now, the memory profile is dumped to text (stderr by default, but
honors the sanitizer_common log_path flag). It is dumped in either a
default verbose format, or an optional terse format.
This patch also adds a set of tests for the core functionality.
Differential Revision: https://reviews.llvm.org/D87120
While sanitizers don't use C++ standard library, we could still end
up accidentally including or linking it just by the virtue of using
the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these
accidental dependencies.
Differential Revision: https://reviews.llvm.org/D88922
TSan relies on C++ headers, so when libc++ is being built as part of
the runtimes build, include an explicit dependency on cxx-headers which
is the same approach that's already used for other sanitizers.
Differential Revision: https://reviews.llvm.org/D88912
[11/11] patch series to port ASAN for riscv64
These changes allow using ASAN on RISCV64 architecture.
The majority of existing tests are passing. With few exceptions (see below).
Tests we run on qemu and on "HiFive Unleashed" board.
Tests run:
```
Asan-riscv64-inline-Test - pass
Asan-riscv64-inline-Noinst-Test - pass
Asan-riscv64-calls-Noinst-Test - pass
Asan-riscv64-calls-Test - pass
```
Lit tests:
```
RISCV64LinuxConfig (282 supported, few failures)
RISCV64LinuxDynamicConfig (289 supported, few failures)
```
Lit failures:
```
TestCases/malloc_context_size.cpp - asan works, but backtrace misses some calls
TestCases/Linux/malloc_delete_mismatch.cpp - asan works, but backtrace misses some calls
TestCases/Linux/static_tls.cpp - "Can't guess glibc version" (under debugging)
TestCases/asan_and_llvm_coverage_test.cpp - missing libclang_rt.profile-riscv64.a
```
These failures are under debugging currently and shall be addressed in a
subsequent commits.
Depends On D87581
Reviewed By: eugenis, vitalybuka
Differential Revision: https://reviews.llvm.org/D87582
It's actually not safe to call TEST_BIG_ENDIAN here, since we may be
running from the builtins build (i.e builtins-config-ix) context where
TEST_COMPILE_ONLY is set since without builtins already built we may
fail to link, and TEST_BIG_ENDIAN internally performs tests which may
fail to link without builtins.
Fortunately powerpc is the only target that uses this information here and
we actually already know the whether we are targeting the LE variant due
to earlier macro checks, so we can simply this to remove our reliance on
TEST_BIG_ENDIAN.
Reviewed By: hubert.reinterpretcast, Whitney
Differential Revision: https://reviews.llvm.org/D88608
This patch enables support for building compiler-rt builtins for 32-bit
Power arch on AIX. For now, we leave out the specialized ppc builtin
implementations for 128-bit long double and friends since those will
need some special handling for AIX.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87383
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
The introduction of find_library for ncurses caused more issues than it solved problems. The current open issue is it makes the static build of LLVM fail. It is better to revert for now, and get back to it later.
Revert "[CMake] Fix an issue where get_system_libname creates an empty regex capture on windows"
This reverts commit 1ed1e16ab8.
Revert "Fix msan build"
This reverts commit 34fe9613dd.
Revert "[CMake] Always mark terminfo as unavailable on Windows"
This reverts commit 76bf26236f.
Revert "[CMake] Fix OCaml build failure because of absolute path in system libs"
This reverts commit 8e4acb82f7.
Revert "[CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF"
This reverts commit 495f91fd33.
Revert "Use find_library for ncurses"
This reverts commit a52173a3e5.
Differential revision: https://reviews.llvm.org/D86521
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Simply don't mark the file as C and CMake will recognize the rest.
This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple.
Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09.
Afterwards workarounds were added for MinGW and Apple:
* https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
* https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb
The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other.
The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287).
Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Example error:
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D86308
Fixes a build failure in the Darwin kernel. Tested with:
% nm -mU lib/libclang_rt.cc_kext_x86_64h_osx.a | grep __llvm_profile_raw_version
rdar://67809173
libtool already produces a table of contents, and ranlib just gives
spurious errors because it doesn't understand universal binaries.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86365
This reverts commit d58fd4e521. This broke
compiler-rt compilation on macOS:
codesign --sign - /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/clang/12.0.99/lib/darwin/libclang_rt.tsan_ios_dynamic.dylib
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_amd64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_aarch64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
Undefined symbols for architecture arm64:
"_wrap__setjmp", referenced from:
substitution__setjmp in tsan_interceptors_posix.cpp.o
"_wrap_setjmp", referenced from:
substitution_setjmp in tsan_interceptors_posix.cpp.o
"_wrap_sigsetjmp", referenced from:
substitution_sigsetjmp in tsan_interceptors_posix.cpp.o
ld: symbol(s) not found for architecture arm64
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead.
Instead enable the ASM language and mark the files as being ASM.
[525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o
/opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
/opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '('
.section .text
^
1 error generated.
Fixed Clang not being passed as the assembly compiler for compiler-rt runtime build.
Patch By: tambre
Differential Revision: https://reviews.llvm.org/D85706
D85820 introduced a bug where LLVM_ENABLE_TERMINFO was set to true when
the library was found, even when the user had set
-DLLVM_ENABLE_TERMINFO=OFF.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D86173
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Differential revision: https://reviews.llvm.org/D85820
* Add SystemZ to the list of supported architectures.
* XFAIL a few tests.
Coverage reporting is broken, and is not easy to fix (see comment in
coverage.test). Interaction with sanitizers needs to be investigated
more thoroughly, since they appear to reduce coverage in certain cases.
A recent change broke `ninja check-asan` on Darwin by causing an error
during linking of ASan unit tests [1].
Move the addition of `-ObjC` compiler flag outside of the new
`if(COMPILER_RT_STANDALONE_BUILD)` block. It doesn't add any global
flags (e.g, `${CMAKE_CXX_FLAGS}`) and the decision to add is based
solely on source paths (`${source_rpath}`).
[1] 8b2fcc42b8, https://reviews.llvm.org/D84466
Differential Revision: https://reviews.llvm.org/D85057
for device simulators
This change separates out the iOS/tvOS/watchOS simulator slices from the "libclang_rt.<os>.a"
fat archive, by moving them out to their own "libclang_rt.<os>sim.a" static archive.
This allows us to build and to link with an arm64 device simulator slice for the simulators running
on Apple Silicons, and to distribute it in one archive alongside the Intel simulator slices.
Differential Revision: https://reviews.llvm.org/D84564
When attempting to build compiler-rt on a developer transition kit, the
build would fail due to `.S` files not being handled properly by the
Ninja generator. Rather than conditionalising on Xcode, conditionalise
to Darwin. Because we know that the system compiler is clang based, it
will always properly handle the pre-processing based on the extension.
Differential Revision: https://reviews.llvm.org/D84333
In a build with -DLLVM_ENABLE_LTO=Thin:
$ ninja TSanitizer-x86_64-Test-Nolibc
[1/1] Generating Sanitizer-x86_64-Test-Nolibc
FAILED: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-x86_64-Test-Nolibc
sanitizer_nolibc_test_main.x86_64.o: file not recognized: file format not recognized
because -flto=thin is getting passed to the clang_compile step.
For non-standalone builds, global compilation flags shouldn't be passed to compiler-rt tests, only the flags the test specifies.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D84466
Kazushi (Jam) Marukawa