summaryrefslogtreecommitdiffstats
path: root/compiler-rt/cmake/builtin-config-ix.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Separate the detection Darwin platforms architectures for theDan Liew2019-09-131-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | built-ins from the rest of compiler-rt. The detection of supported platform (os) architectures for Darwin relies on the `darwin_test_archs()` CMake function. This is used both for building the builtins (`builtin-config-ix.cmake`) and for the rest of the compiler-rt (`config-ix.cmake`). `darwin_test_archs()` implements a cache, presumably to speed up CMake re-configures. Unfortunately this caching is buggy because it depends on external global state (i.e. the `TEST_COMPILE_ONLY` variable) and this is not taken into account. For `config-ix.cmake` `TEST_COMPILE_ONLY` is not set and for `builtin-config-ix.cmake` `TEST_COMPILE_ONLY` is set to `On`. This makes the `darwin_test_archs()` function racey in the sense that a call from one calling context will poison the cache for the other calling context. This is actually an issue George Karpenkov discovered a while back and had an incomplete patch for (https://reviews.llvm.org/D45337) but this was never merged. To workaround this, this patch switches to using a different set of variables for the platform architecture builtins, i.e. `DARWIN_<OS>_ARCHS` -> `DARWIN_<OS>_BUILTIN_ARCHS`. This avoids the cache poisoning problem because the cached variable names are different. This also has the advantage that the the configured architectures for builtins and the rest of the compiler-rt are now independent and can be set differently if necessary. Note in `darwin_test_archs()` we also now pass `-w` to the compiler because `try_compile_only()` treats compiler warnings as errors. This was extremely fragile because compiler warnings (can easily appear due to a buggy compiler or SDK headers) would cause compiler-rt to think an architecture on Darwin wasn't supported. rdar://problem/48637491 llvm-svn: 371871
* Enable compiler-rt on SPARCRainer Orth2019-07-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward: - Add 32 and 64-bit sparc to compiler-rt - lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc) There's one issue of note: many asan tests fail to compile on Solaris/SPARC: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc, which doesn't have the problem above and works just fine. With this patch, sparcv9-sun-solaris2.11 test results are pretty good: Failing Tests (9): Builtins-sparc-sunos :: divtc3_test.c Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c Builtins-sparcv9-sunos :: divtc3_test.c [...] UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal patches either currently in review or about to be submitted. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D40943 llvm-svn: 365880
* [macOS] stop generating the libclang_rt.10.4.a library for macOS 10.4Alex Lorenz2018-08-081-14/+0
| | | | | | | | The support for macOS 10.4 has been dropped by Xcode 10. rdar://42876880 llvm-svn: 339277
* Revert "[cmake] [ARM] Check if VFP is supported before including any VFP ↵Azharuddin Mohammed2018-05-241-6/+0
| | | | | | | | builtins" This reverts commit 2a10f5da5acb1b51d0a2ecf13dca0bf1de859db2. llvm-svn: 333232
* [cmake] [ARM] Check if VFP is supported before including any VFP builtinsAzharuddin Mohammed2018-05-241-0/+6
| | | | | | | | | | | | | | | | | | | Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for armv7. This causes errors with builtins that utililize VFP instructions. With this change we first check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined) before including such builtins. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 333216
* Add basic compiler-rt builtins support for hexagon.Sid Manning2018-05-091-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
* [PATCH] [compiler-rt, RISCV] Support builtins for RISC-VShiva Chen2018-03-011-1/+3
| | | | | | | | | | | Summary: Support builtins for RISC-V, RV32 and RV64. Reviewers: asb, apazos, mgrang Differential Revision: https://reviews.llvm.org/D42958 llvm-svn: 326420
* Add powerpc64 to compiler-rt build infrastructure.Sterling Augustine2017-11-301-1/+1
| | | | | | | | Now that we have disabled the run-forever tests, and cleaned up the intel 80-bit float based tests, we should be able to enable testing compiler-rt for powerpc64. llvm-svn: 319474
* [cmake] Fix the list of arm32 architecturesMartin Storsjo2017-08-311-1/+0
| | | | | | | This was accidentally changed in SVN r311924, which was only supposed to change the behaviour for x86. llvm-svn: 312230
* Reland r311842 - [cmake] Remove i686 target that is duplicate to i386Michal Gorny2017-08-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Remove the explicit i686 target that is completely duplicate to the i386 target, with the latter being used more commonly. 1. The runtime built for i686 will be identical to the one built for i386. 2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion on the clang end which has to expect either of them. 3. The checks are based on wrong assumption that __i686__ is defined for all newer x86 CPUs. In fact, it is only declared when -march=i686 is explicitly used. It is not available when a more specific (or newer) -march is used. Curious enough, if CFLAGS contain -march=i686, the runtime will be built both for i386 and i686. For any other value, only i386 variant will be built. Differential Revision: https://reviews.llvm.org/D26764 llvm-svn: 311924
* Revert r311842 - [cmake] Remove i686 target that is duplicate to i386Michal Gorny2017-08-271-2/+1
| | | | | | | The required change in clang is being reverted because of the Android build bot failure. llvm-svn: 311859
* [cmake] Remove i686 target that is duplicate to i386Michal Gorny2017-08-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Remove the explicit i686 target that is completely duplicate to the i386 target, with the latter being used more commonly. 1. The runtime built for i686 will be identical to the one built for i386. 2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion on the clang end which has to expect either of them. 3. The checks are based on wrong assumption that __i686__ is defined for all newer x86 CPUs. In fact, it is only declared when -march=i686 is explicitly used. It is not available when a more specific (or newer) -march is used. Curious enough, if CFLAGS contain -march=i686, the runtime will be built both for i386 and i686. For any other value, only i386 variant will be built. Differential Revision: https://reviews.llvm.org/D26764 llvm-svn: 311842
* Revert rL309634 until upstream buildbots have upgraded libc.Sterling Augustine2017-08-011-1/+1
| | | | llvm-svn: 309704
* Add powerpc64 to compiler-rt build infrastructure.Sterling Augustine2017-07-311-1/+1
| | | | | | | | | | | | | | Summary: Add powerpc64 to compiler-rt build infrastructure. Reviewers: timshen Reviewed By: timshen Subscribers: nemanjai, dberris, mgorny, aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D36108 llvm-svn: 309634
* Allow armv{7,7s,7k,7m,7em} buildsJonathan Roelofs2017-05-241-1/+1
| | | | llvm-svn: 303765
* Roll back r301831 to fix broken powerpc64le tests.Sterling Augustine2017-05-021-1/+1
| | | | | | http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/5941 llvm-svn: 301935
* Add powerpc64 and powerpc64le to build infrastructure.Sterling Augustine2017-05-011-1/+1
| | | | | | From Phab D32031. llvm-svn: 301831
* [Builtin] [ARM] Update CMake to support the build of armv6mWeiming Zhao2017-01-191-1/+1
| | | | | | | | | | | | | | | | | | Summary: Setting -DCOMPILER_RT_TEST_TARGET_TRIPLE=armv6m-none-eabi will enable the build of builtin functions ARMv6m. Currently, only those asms that support armv6m are added. TODO:All asm sin ARM_EABI_Sources are ported for thumb1 so Thumb1_EABI_Sources will be deprecated. Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: aemerson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28463 llvm-svn: 292504
* builtins: switch to c11 from c99Saleem Abdulrasool2016-11-291-1/+1
| | | | | | | | | | | | | | This fixes an incorrect standard usage of GNU99 when the compiler check was for the ISO standard C99. Furthermore, bump the dependency up to C11. The motivation for this change is ARM EHABI compatibility with clang 3.8. We rely on a type definition redefinition which causes an error with -Werror builds. This is problematic for FreeBSD builds. Switching to C11 allows the compatibility without the unnecessary pedantic warning. The alternative would be to clutter the support header with a `pragma clang diagnostic ignore`. GCC 4.8+ and the supported clang revisions along with MSVC support enough of C11 to allow building the builtins in C11 mode. No functional change intended. llvm-svn: 288099
* [XRay][compiler-rt] Disable XRay instrumentation of the XRay runtime.Dean Michael Berris2016-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Adds a CMake check for whether the compiler used to build the XRay library supports XRay-instrumentation. If the compiler we're using does support the `-fxray-instrument` flag (i.e. recently-built Clang), we define the XRAY_NEVER_INSTRUMENT macro that then makes sure that the XRay runtime functions never get XRay-instrumented. This prevents potential weirdness involved with building the XRay library with a Clang that supports XRay-instrumentation, and is attempting to XRay-instrument the build of compiler-rt. Reviewers: majnemer, rSerge, echristo Subscribers: mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D26597 llvm-svn: 287068
* [compiler-rt] Use flags found when configuring builtins during compilationFrancis Ricci2016-08-221-3/+0
| | | | | | | | | | | | Summary: This fixes the omission of -fPIC when building the builtins. Reviewers: compnerd, beanz Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D23729 llvm-svn: 279469
* [CMake] Renaming test variable to be consistentChris Bieneman2016-08-151-1/+1
| | | | | | Based on post-commit review by compnerd. llvm-svn: 278728
* [CMake] If the compiler supports _Atomic include atomic.c in builtins librariesChris Bieneman2016-08-121-0/+10
| | | | | | This fixes a long-standing TODO by implementing a compiler check for supporting the _Atomic keyword. If the _Atomic keyword is supported by the compiler we should include it in the builtin library sources. llvm-svn: 278454
* Revert r276256 - Attempt to fix clang-cmake-mips after r268977.Daniel Sanders2016-07-211-6/+0
| | | | | | It didn't fix the problem on the buildbot. CAN_TARGET_mips64 is still true. llvm-svn: 276258
* Attempt to fix clang-cmake-mips after r268977.Daniel Sanders2016-07-211-0/+6
| | | | | | | | I think it's wiped out the build area and fully-reconfigured for the first time since r268977. This seems to have caused Mips64 to become enabled when it wasn't before because compiling with -mabi=64 succeeds but linking with -mabi=64 fails. llvm-svn: 276256
* [CMake] Support platform building builtins without a full toolchainChris Bieneman2016-05-091-0/+169
Summary: This patch adds support for building lib/builtins without a fully functioning toolchain. It allows you to bootstrap a cross-compiler, which previously couldn't be done with CMake. This patch contains the following specific changes: * Split builtin-specific code out of config-ix.cmake into builtin-config-ix.cmake * Split some common CMake functionality needed by both builtins and sanitizers into base-config-ix.cmake * Made lib/builtins/CMakeLists.txt able to be a top-level CMake configuration I have tested this on Darwin targeting embedded Darwin, and on FreeBSD x86_64 targeting FreeBSD AArch64. This patch depends on http://reviews.llvm.org/D19692, and is the last part of http://reviews.llvm.org/D16653. Reviewers: samsonov, iains, jroelofs Subscribers: compnerd, aemerson, tberghammer, danalbert, srhines, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D19742 llvm-svn: 268977
OpenPOWER on IntegriCloud