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
Neither the Illumos `ld` nor the Solaris 11.3 one support the `--version-script` and
`z gnu-linker-script-compat` options, which breaks the `compiler-rt` build.
This patch checks for both options instead of hardcoding their use.
Tested on `amd-pc-solaris2.11` (all of Solaris 11.4, 11.3, and Illumos).
Differential Revision: https://reviews.llvm.org/D84559
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
Otherwise if 'ld' is an older system LLD (FreeBSD; or if someone adds 'ld' to
point to an LLD from a different installation) which does not support the
current ModuleSummaryIndex::BitCodeSummaryVersion, the test will fail.
Add lit feature 'binutils_lto'. GNU ld is more common than GNU gold, so
we can just require 'is_binutils_lto_supported' to additionally support GNU ld.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D84133
Most of the code in compiler_rt is C code. However, clang_rt.profile
contains the InstrProfilingRuntime.cpp file, which builds as C++. This
means that including e.g. <stdint.h> will actually include libc++'s
<stdint.h> and then #include_next the system's <stdint.h>. However, if
the target we're building compiler-rt for isn't supported by libc++,
this will lead to a failure since libc++'s <stdint.h> includes <__config>,
which performs various checks.
Since the goal seems to *not* be including any header from the C++ Standard
Library in clang_rt.profile, using -nostdinc++ to ensure that doesn't
happen unknowingly seems to make sense.
rdar://65852694
Differential Revision: https://reviews.llvm.org/D84205
This uses a special set of flags given to unittests to work around warnings raised by googletest and googlemock. This should bring the sanitizer bots back to green.
For Android only, compiler-rt used detect_target_arch to select the
architecture to target. detect_target_arch was added in Sept 2014
(SVN r218605). At that time, compiler-rt selected the default arch
using ${LLVM_NATIVE_ARCH}, which seems to have been the host
architecture and therefore not suitable for cross-compilation.
The compiler-rt build system was refactored in Sept 2015 (SVN r247094
and SVN r247099) to use COMPILER_RT_DEFAULT_TARGET_TRIPLE to control
the target arch rather than LLVM_NATIVE_ARCH. This approach is simpler
and also works for Android cross-compilation, so remove the
detect_target_arch function.
Android targets i686, but compiler-rt seems to identify 32-bit x86 as
"i386". For Android, we were previously calling add_default_target_arch
with i386, and calling add_default_target_arch with i686 does not build
anything. i686 is not listed in builtin-config-ix.cmake,
ALL_BUILTIN_SUPPORTED_ARCH.
Differential Revision: https://reviews.llvm.org/D82148
Split filter_builtin_sources into two functions:
- filter_builtin_sources that removes generic files when an
arch-specific file is selected.
- darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE
lists (using the files in lib/builtins/Darwin-excludes).
darwin_filter_builtin_sources delegates to filter_builtin_sources.
Previously, lib/builtins/CMakeLists.txt had a number of calls to
filter_builtin_sources (with a confusing/broken use of the
`excluded_list` parameter), as well as a redundant arch-vs-generic
filtering for the non-Apple code path at the end of the file. Replace
all of this with a single call to filter_builtin_sources.
Remove i686_SOURCES. Previously, this list contained only the
arch-specific files common to 32-bit and 64-bit x86, which is a strange
set. Normally the ${ARCH}_SOURCES list contains everything needed for
the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH.
NFCI, but i686_SOURCES won't be defined, and the order of files in
${arch}_SOURCES lists will change.
Differential Revision: https://reviews.llvm.org/D82151
At this point in this code:
- COMPILER_RT_DEFAULT_TARGET_TRIPLE is "i686-linux-android"
- arch is "i386"
The get_compiler_rt_target function currently turns that into:
i686-android-linux-android
The ${COMPILER_RT_OS_SUFFIX} is "-android" and redundant, so stop
adding it.
The get_compiler_rt_target() function is used for the
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR mode that isn't normally used with
Android.
Differential Revision: https://reviews.llvm.org/D82150
Summary:
This patch implements dynamic stack allocation for the VE target. Changes:
* compiler-rt: `__ve_grow_stack` to request stack allocation on the VE.
* VE: base pointer support, dynamic stack allocation.
Differential Revision: https://reviews.llvm.org/D79084
When build in runtime bulid mode with LLVM_ENABLE_RUNTIMES,
the base-config-ix.cmake will complain about two errors.
One is empty string in replace, the other one is unknown `TEST_BIG_ENDIAN ` command.
This patch fix it so that we can test runtime build.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80040
Since setting COMPILER_RT_USE_BUILTINS_LIBRARY would remove -z,defs
flag, missing builtins library would continue to build unnoticed.
Explicitly emit an error in such case.
Differential Revision: https://reviews.llvm.org/D79470
Only add CMAKE_EXE_LINKER_FLAGS when in a standalone bulid.
Or else CMAKE_EXE_LINKER_FLAGS contains flags for build compiler of Clang/llvm.
This might not be the same as what the COMPILER_RT_TEST_COMPILER supports.
eg: the build compiler use lld linker and we use it to build clang with
default ld linker then to be tested clang will complain about lld
options like --color-diagnostics.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D78373
Summary:
When doing cross-compilation from Linux to MacOS we don't have
access to have access to `xcodebuild` and therefore need a way
to set the SDK version from the outside.
Fixes https://reviews.llvm.org/D68292#1853594 for me.
Reviewers: delcypher, yln
Reviewed By: delcypher
Subscribers: #julialang, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77026
https://github.com/apple/swift/pull/30112/ makes the Swift standard
library for iOS build for arm64e. If you're building Swift against your
own LLVM, this in turn requires having the builtins built for arm64e,
otherwise you won't be able to use the builtins (which will in turn lead
to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins
build for arm64e to fix this.
Differential Revision: https://reviews.llvm.org/D76041
Patch by Zhizhou Yang!
In his own words:
"""
Currently compiler-rt doesn't officially support either PGO
instrumentation or use PGO profdata to build it.
PGO related flags are passed into compiler-rt since rL372209, and
causing bugs: 45022, crbug:1018840
This patch adds several checks in compiler-rt to disable PGO related
flags and provides a flag to turn on PGO for compiler-rt if needed.
"""
Differential Revision: https://reviews.llvm.org/D75499
platforms.
For the simulators this changes the following compilation flags (
used both for building the runtime and lit tests).
iOS simulator: `-miphoneos-version-min` -> `-mios-simulator-version-min`
watchOS simulator: `-mwatchos-version-min` -> `-mwatchos-simulator-version-min`
tvOS simulator: `-mtvos-version-min` -> `-mtvos-simulator-version-min`
rdar://problem/59463146
XRay builds uses llvm-config to obtain the ldflags and libs and then
passes those to CMake. Unfortunately, this breaks on Windows because
CMake tries to interpret backslashes followed by certain characters
as flags. We need to rewrite these into forward slashes that are used
by CMake (even on Windows).
Differential Revision: https://reviews.llvm.org/D73523
Summary:
Since commit c299d1981d scudo
standalone can't be built without including sys/auxv.h.
I do not have that file on my system, and my builds have failed
when trying to simply build "all" runtimes. Assuming that "all"
means "all possible given the current environment" we need to
guard the setting of COMPILER_RT_HAS_SCUDO_STANDALONE=TRUE by
first checking if sys/auxv.h can be found.
Reviewers: pcc, cryptoad
Reviewed By: pcc
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73631
David Tenty