maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/cmake/base-config-ix.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

262 lines
11 KiB
CMake
Raw Normal View History

[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
# The CompilerRT build system requires CMake version 2.8.8 or higher in order
# to use its support for building convenience "libraries" as a collection of
# .o files. This is particularly useful in producing larger, more complex
# runtime libraries.
include(CheckIncludeFile)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
include(CheckCXXSourceCompiles)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
check_include_file(unwind.h HAVE_UNWIND_H)
[test] Disable sunrpc tests when rpc/xdr.h is missing Disable tests requiring sunrpc when the relevant headers are missing. In order to accommodate that, move the header check from sanitizer_common to base-config-ix, and define the check result as a global variable there. Use it afterwards both for definition needed by sanitizer_common, and to control 'sunrpc' test feature. While at it, remove the append_have_file_definition macro that was used only once, and no longer fits the split check-definition. Bug report: https://github.com/google/sanitizers/issues/974 Differential Revision: https://reviews.llvm.org/D47819 llvm-svn: 351109
2019-01-15 03:18:34 +08:00
# Used by sanitizer_common and tests.
check_include_file(rpc/xdr.h HAVE_RPC_XDR_H)
if (NOT HAVE_RPC_XDR_H)
set(HAVE_RPC_XDR_H 0)
endif()
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
# Top level target used to build all compiler-rt libraries.
add_custom_target(compiler-rt ALL)
[CMake] Add top-level install-compiler-rt target This is a wrapper target of all the component install targets. This wrapper target will be used by the new LLVM runtimes directory to connect top-level targets to the runtime project target. llvm-svn: 279333
2016-08-20 06:17:46 +08:00
add_custom_target(install-compiler-rt)
[compiler-rt] Add install-*-stripped targets These targets strip during installation, and are required to support install-distribution-stripped in LLVM (to support a stripped distribution). LLVM has an add_llvm_install_targets function for this purpose, but we can't rely on LLVM being present. Differential Revision: https://reviews.llvm.org/D40687 llvm-svn: 319569
2017-12-02 03:06:29 +08:00
add_custom_target(install-compiler-rt-stripped)
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 20:56:34 +08:00
set_property(
TARGET
compiler-rt
install-compiler-rt
install-compiler-rt-stripped
PROPERTY
FOLDER "Compiler-RT Misc"
)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
[CMake] Support constructing output paths from LLVM variables This tweak to constructing output paths allows compiler-rt to use LLVM output variables if they are set regardless of whether or not the build is in-tree. llvm-svn: 271749
2016-06-04 07:15:04 +08:00
# Setting these variables from an LLVM build is sufficient that compiler-rt can
# construct the output paths, so it can behave as if it were in-tree here.
if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND PACKAGE_VERSION)
set(LLVM_TREE_AVAILABLE On)
endif()
if (LLVM_TREE_AVAILABLE)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
# Compute the Clang version from the LLVM version.
# FIXME: We should be able to reuse CLANG_VERSION variable calculated
# in Clang cmake files, instead of copying the rules here.
string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
${PACKAGE_VERSION})
# Setup the paths where compiler-rt runtimes and headers should be stored.
set(COMPILER_RT_OUTPUT_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION})
set(COMPILER_RT_EXEC_OUTPUT_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
set(COMPILER_RT_INSTALL_PATH lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests."
${LLVM_INCLUDE_TESTS})
option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered"
${LLVM_ENABLE_WERROR})
Use host's executable suffix for clang when cross-compiling compiler-rt When cross-compiling compiler-rt as part of LLVM e. g. for Linux on a Windows host and using the just-built clang as cross-compiler, we set the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty string in the nested cmake invocation for building builtins. But the compiler for compiling test cases is meant to be run on host, therefore it may have the '.exe' suffix. Handle this by asking cmake about the host system. Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com> Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D67401 llvm-svn: 371754
2019-09-13 02:44:47 +08:00
[InstrProf] Implement static profdata registration Summary: The motivating use case is eliminating duplicate profile data registered for the same inline function in two object files. Before this change, users would observe multiple symbol definition errors with VC link, but links with LLD would succeed. Users (Mozilla) have reported that PGO works well with clang-cl and LLD, but when using LLD without this static registration, we would get into a "relocation against a discarded section" situation. I'm not sure what happens in that situation, but I suspect that duplicate, unused profile information was retained. If so, this change will reduce the size of such binaries with LLD. Now, Windows uses static registration and is in line with all the other platforms. Reviewers: davidxl, wmi, inglorion, void, calixte Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57929 llvm-svn: 353547
2019-02-09 03:03:50 +08:00
# Use just-built Clang to compile/link tests on all platforms.
Use host's executable suffix for clang when cross-compiling compiler-rt When cross-compiling compiler-rt as part of LLVM e. g. for Linux on a Windows host and using the just-built clang as cross-compiler, we set the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty string in the nested cmake invocation for building builtins. But the compiler for compiling test cases is meant to be run on host, therefore it may have the '.exe' suffix. Handle this by asking cmake about the host system. Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com> Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D67401 llvm-svn: 371754
2019-09-13 02:44:47 +08:00
if (CMAKE_CROSSCOMPILING)
if (CMAKE_HOST_WIN32)
set(_host_executable_suffix ".exe")
else()
set(_host_executable_suffix "")
endif()
else()
set(_host_executable_suffix ${CMAKE_EXECUTABLE_SUFFIX})
endif()
[InstrProf] Implement static profdata registration Summary: The motivating use case is eliminating duplicate profile data registered for the same inline function in two object files. Before this change, users would observe multiple symbol definition errors with VC link, but links with LLD would succeed. Users (Mozilla) have reported that PGO works well with clang-cl and LLD, but when using LLD without this static registration, we would get into a "relocation against a discarded section" situation. I'm not sure what happens in that situation, but I suspect that duplicate, unused profile information was retained. If so, this change will reduce the size of such binaries with LLD. Now, Windows uses static registration and is in line with all the other platforms. Reviewers: davidxl, wmi, inglorion, void, calixte Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57929 llvm-svn: 353547
2019-02-09 03:03:50 +08:00
set(COMPILER_RT_TEST_COMPILER
Use host's executable suffix for clang when cross-compiling compiler-rt When cross-compiling compiler-rt as part of LLVM e. g. for Linux on a Windows host and using the just-built clang as cross-compiler, we set the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty string in the nested cmake invocation for building builtins. But the compiler for compiling test cases is meant to be run on host, therefore it may have the '.exe' suffix. Handle this by asking cmake about the host system. Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com> Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D67401 llvm-svn: 371754
2019-09-13 02:44:47 +08:00
${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${_host_executable_suffix})
[InstrProf] Implement static profdata registration Summary: The motivating use case is eliminating duplicate profile data registered for the same inline function in two object files. Before this change, users would observe multiple symbol definition errors with VC link, but links with LLD would succeed. Users (Mozilla) have reported that PGO works well with clang-cl and LLD, but when using LLD without this static registration, we would get into a "relocation against a discarded section" situation. I'm not sure what happens in that situation, but I suspect that duplicate, unused profile information was retained. If so, this change will reduce the size of such binaries with LLD. Now, Windows uses static registration and is in line with all the other platforms. Reviewers: davidxl, wmi, inglorion, void, calixte Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57929 llvm-svn: 353547
2019-02-09 03:03:50 +08:00
set(COMPILER_RT_TEST_CXX_COMPILER
Use host's executable suffix for clang when cross-compiling compiler-rt When cross-compiling compiler-rt as part of LLVM e. g. for Linux on a Windows host and using the just-built clang as cross-compiler, we set the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty string in the nested cmake invocation for building builtins. But the compiler for compiling test cases is meant to be run on host, therefore it may have the '.exe' suffix. Handle this by asking cmake about the host system. Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com> Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D67401 llvm-svn: 371754
2019-09-13 02:44:47 +08:00
${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++${_host_executable_suffix})
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
else()
# Take output dir and install path from the user.
set(COMPILER_RT_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR} CACHE PATH
"Path where built compiler-rt libraries should be stored.")
set(COMPILER_RT_EXEC_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin CACHE PATH
"Path where built compiler-rt executables should be stored.")
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(COMPILER_RT_INSTALL_PATH "" CACHE PATH
"Prefix for directories where built compiler-rt artifacts should be installed.")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests." OFF)
option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered" OFF)
# Use a host compiler to compile/link tests.
set(COMPILER_RT_TEST_COMPILER ${CMAKE_C_COMPILER} CACHE PATH "Compiler to use for testing")
set(COMPILER_RT_TEST_CXX_COMPILER ${CMAKE_CXX_COMPILER} CACHE PATH "C++ Compiler to use for testing")
endif()
if("${COMPILER_RT_TEST_COMPILER}" MATCHES "clang[+]*$")
set(COMPILER_RT_TEST_COMPILER_ID Clang)
elseif("${COMPILER_RT_TEST_COMPILER}" MATCHES "clang.*.exe$")
set(COMPILER_RT_TEST_COMPILER_ID Clang)
else()
set(COMPILER_RT_TEST_COMPILER_ID GNU)
endif()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
function(extend_install_path joined_path current_segment)
if("${current_segment}" STREQUAL "")
set(temp_path "${COMPILER_RT_INSTALL_PATH}")
elseif("${COMPILER_RT_INSTALL_PATH}" STREQUAL "")
set(temp_path "${current_segment}")
elseif(IS_ABSOLUTE "${current_segment}")
message(WARNING "Since \"${current_segment}\" is absolute, it overrides COMPILER_RT_INSTALL_PATH: \"${COMPILER_RT_INSTALL_PATH}\".")
set(temp_path "${current_segment}")
else()
set(temp_path "${COMPILER_RT_INSTALL_PATH}/${current_segment}")
endif()
set(${joined_path} "${temp_path}" PARENT_SCOPE)
endfunction()
Allow builds to set COMPILER_RT_OS_DIR differently from CMAKE_SYSTEM_NAME llvm-svn: 303817
2017-05-25 06:41:49 +08:00
if(NOT DEFINED COMPILER_RT_OS_DIR)
[compiler-rt] Fix COMPILER_RT_OS_DIR for Android Android has its own CMAKE_SYSTEM_NAME, but the OS is Linux (Android target triples look like aarch64-none-linux-android21). The driver will therefore search for compiler-rt libraries in the "linux" directory and not the "android" directory, so the default placement of Android compiler-rt libraries was incorrect. You could fix it by specifying COMPILER_RT_OS_DIR manually, but it also makes sense to fix the default, to save others from having to discover and fix the issue for themselves.
2021-07-30 07:46:38 +08:00
if(ANDROID)
# The CMAKE_SYSTEM_NAME for Android is Android, but the OS is Linux and the
# driver will search for compiler-rt libraries in the "linux" directory.
set(COMPILER_RT_OS_DIR linux)
else()
string(TOLOWER ${CMAKE_SYSTEM_NAME} COMPILER_RT_OS_DIR)
endif()
Allow builds to set COMPILER_RT_OS_DIR differently from CMAKE_SYSTEM_NAME llvm-svn: 303817
2017-05-25 06:41:49 +08:00
endif()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(COMPILER_RT_OUTPUT_LIBRARY_DIR
${COMPILER_RT_OUTPUT_DIR}/lib)
extend_install_path(default_install_path lib)
set(COMPILER_RT_INSTALL_LIBRARY_DIR "${default_install_path}" CACHE PATH
"Path where built compiler-rt libraries should be installed.")
else(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
set(COMPILER_RT_OUTPUT_LIBRARY_DIR
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
${COMPILER_RT_OUTPUT_DIR}/lib/${COMPILER_RT_OS_DIR})
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
extend_install_path(default_install_path "lib/${COMPILER_RT_OS_DIR}")
set(COMPILER_RT_INSTALL_LIBRARY_DIR "${default_install_path}" CACHE PATH
"Path where built compiler-rt libraries should be installed.")
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
endif()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
extend_install_path(default_install_path bin)
set(COMPILER_RT_INSTALL_BINARY_DIR "${default_install_path}" CACHE PATH
"Path where built compiler-rt executables should be installed.")
extend_install_path(default_install_path include)
set(COMPILER_RT_INSTALL_INCLUDE_DIR "${default_install_path}" CACHE PATH
"Path where compiler-rt headers should be installed.")
extend_install_path(default_install_path share)
set(COMPILER_RT_INSTALL_DATA_DIR "${default_install_path}" CACHE PATH
"Path where compiler-rt data files should be installed.")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
if(APPLE)
[compiler-rt] Fix running tests on macOS when XCode is not installed Summary: If XCode is not installed, `xcodebuild -version -sdk macosx Path` will give xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance In this case the variable OSX_SYSROOT will be empty and OSX_SYSROOT_FLAG is set to "-isysroot" (without a path). This then causes the CompilerRTUnitTestCheckCxx target failed to for me because "${COMPILER_RT_TEST_COMPILER} ${OSX_SYSROOT_FLAG} -E" expanded to "clang -isysroot -E". This results in a warning "sysroot -E does not exist" and the target fails to run because the C++ headers cannot be found. Reviewers: beanz, kubamracek Reviewed By: beanz Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65323 llvm-svn: 367170
2019-07-27 20:30:15 +08:00
# On Darwin if /usr/include/c++ doesn't exist, the user probably has Xcode but
# not the command line tools (or is using macOS 10.14 or newer). If this is
# the case, we need to find the OS X sysroot to pass to clang.
if(NOT EXISTS /usr/include/c++)
execute_process(COMMAND xcrun -sdk macosx --show-sdk-path
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
OUTPUT_VARIABLE OSX_SYSROOT
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)
[compiler-rt] Fix running tests on macOS when XCode is not installed Summary: If XCode is not installed, `xcodebuild -version -sdk macosx Path` will give xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance In this case the variable OSX_SYSROOT will be empty and OSX_SYSROOT_FLAG is set to "-isysroot" (without a path). This then causes the CompilerRTUnitTestCheckCxx target failed to for me because "${COMPILER_RT_TEST_COMPILER} ${OSX_SYSROOT_FLAG} -E" expanded to "clang -isysroot -E". This results in a warning "sysroot -E does not exist" and the target fails to run because the C++ headers cannot be found. Reviewers: beanz, kubamracek Reviewed By: beanz Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65323 llvm-svn: 367170
2019-07-27 20:30:15 +08:00
if (NOT OSX_SYSROOT OR NOT EXISTS ${OSX_SYSROOT})
message(WARNING "Detected OSX_SYSROOT ${OSX_SYSROOT} does not exist")
else()
message(STATUS "Found OSX_SYSROOT: ${OSX_SYSROOT}")
set(OSX_SYSROOT_FLAG "-isysroot${OSX_SYSROOT}")
endif()
else()
set(OSX_SYSROOT_FLAG "")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
[compiler-rt] Enable building iOS by default. llvm-svn: 283379
2016-10-06 04:45:36 +08:00
option(COMPILER_RT_ENABLE_IOS "Enable building for iOS" On)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
option(COMPILER_RT_ENABLE_WATCHOS "Enable building for watchOS - Experimental" Off)
option(COMPILER_RT_ENABLE_TVOS "Enable building for tvOS - Experimental" Off)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-13 07:14:02 +08:00
else()
option(COMPILER_RT_DEFAULT_TARGET_ONLY "Build builtins only for the default target" Off)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
[compiler-rt] Fix library suffixes on windows Summary: Make sure that windows libraries contain the suffixes expected by clang. This is expecially important when compiling the windows builtins with clang, as cmake will use .a as the suffix by default. Reviewers: beanz, compnerd Subscribers: llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D24046 llvm-svn: 280854
2016-09-08 04:32:48 +08:00
if(WIN32 AND NOT MINGW AND NOT CYGWIN)
set(CMAKE_SHARED_LIBRARY_PREFIX_C "")
set(CMAKE_SHARED_LIBRARY_PREFIX_CXX "")
set(CMAKE_STATIC_LIBRARY_PREFIX_C "")
set(CMAKE_STATIC_LIBRARY_PREFIX_CXX "")
set(CMAKE_STATIC_LIBRARY_SUFFIX_C ".lib")
set(CMAKE_STATIC_LIBRARY_SUFFIX_CXX ".lib")
endif()
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
macro(test_targets)
# Find and run MSVC (not clang-cl) and get its version. This will tell clang-cl
# what version of MSVC to pretend to be so that the STL works.
set(MSVC_VERSION_FLAG "")
if (MSVC)
execute_process(COMMAND "$ENV{VSINSTALLDIR}/VC/bin/cl.exe"
OUTPUT_QUIET
ERROR_VARIABLE MSVC_COMPAT_VERSION
)
string(REGEX REPLACE "^.*Compiler Version ([0-9.]+) for .*$" "\\1"
MSVC_COMPAT_VERSION "${MSVC_COMPAT_VERSION}")
if (MSVC_COMPAT_VERSION MATCHES "^[0-9].+$")
set(MSVC_VERSION_FLAG "-fms-compatibility-version=${MSVC_COMPAT_VERSION}")
# Add this flag into the host build if this is clang-cl.
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
append("${MSVC_VERSION_FLAG}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Fix some warnings in the MSVC build - Fixes warnings about the ignored -fms-compatibility-version flag. - Fixes warnings about overriding /W4 with /W3 and back. - Fixes a warning where PREFETCH() expanded to nothing in a braceless if block. llvm-svn: 273021
2016-06-18 01:48:52 +08:00
elseif (COMPILER_RT_TEST_COMPILER_ID MATCHES "Clang")
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
# Add this flag to test compiles to suppress clang's auto-detection
# logic.
append("${MSVC_VERSION_FLAG}" COMPILER_RT_TEST_COMPILER_CFLAGS)
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
endif()
endif()
# Generate the COMPILER_RT_SUPPORTED_ARCH list.
if(ANDROID)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
# Examine compiler output to determine target architecture.
detect_target_arch()
[CMake] In r273957, I deleted a line that shouldn't have been removed. llvm-svn: 274030
2016-06-29 00:30:23 +08:00
set(COMPILER_RT_OS_SUFFIX "-android")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif(NOT APPLE) # Supported archs for Apple platforms are generated later
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-13 07:14:02 +08:00
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
add_default_target_arch(${COMPILER_RT_DEFAULT_TARGET_ARCH})
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "i[2-6]86|x86|amd64")
Revert "[Sanitizers] Remove OpenBSD support" + 1 Revert "Fix compiler-rt build on Windows after D89640" This reverts commit a7acee89d68473183cc5021d952a56cdf0ae27d3. This reverts commit d09b08919ca6e206cd981fdea8b19b1d1188e325. Reason: breaks Linux / x86_64 build.
2020-10-20 06:53:34 +08:00
if(NOT MSVC)
[Sanitizers] Remove OpenBSD support (new attempt) - Fixing VS compiler and other cases settings this time. Reviewers: dmajor, hans Reviewed By: hans Differential Revision: https://reviews.llvm.org/D89759
2020-10-20 18:14:26 +08:00
test_target_arch(x86_64 "" "-m64")
test_target_arch(i386 __i386__ "-m32")
Revert "[Sanitizers] Remove OpenBSD support" + 1 Revert "Fix compiler-rt build on Windows after D89640" This reverts commit a7acee89d68473183cc5021d952a56cdf0ae27d3. This reverts commit d09b08919ca6e206cd981fdea8b19b1d1188e325. Reason: breaks Linux / x86_64 build.
2020-10-20 06:53:34 +08:00
else()
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
if (CMAKE_SIZEOF_VOID_P EQUAL 4)
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
test_target_arch(i386 "" "")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
else()
trimming whitespaces llvm-svn: 273263
2016-06-21 22:32:52 +08:00
test_target_arch(x86_64 "" "")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
endif()
compiler-rt: Fix arch detection for ppc64le Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D110377
2021-10-22 07:11:41 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "powerpc64le|ppc64le")
[compiler-rt][cmake][powerpc] Remove TEST_BIG_ENDIAN from base-config-ix.cmake 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
2020-09-30 23:13:20 +08:00
test_target_arch(powerpc64le "" "-m64")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "powerpc")
[compiler-rt][cmake][powerpc] Remove TEST_BIG_ENDIAN from base-config-ix.cmake 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
2020-09-30 23:13:20 +08:00
if(CMAKE_SYSTEM_NAME MATCHES "AIX")
test_target_arch(powerpc "" "-m32")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
[compiler-rt][cmake][powerpc] Remove TEST_BIG_ENDIAN from base-config-ix.cmake 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
2020-09-30 23:13:20 +08:00
test_target_arch(powerpc64 "" "-m64")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "s390x")
test_target_arch(s390x "" "")
Enable compiler-rt on SPARC 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
2019-07-12 16:30:17 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "sparc")
test_target_arch(sparc "" "-m32")
test_target_arch(sparcv9 "" "-m64")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "mipsel|mips64el")
# Gcc doesn't accept -m32/-m64 so we do the next best thing and use
# -mips32r2/-mips64r2. We don't use -mips1/-mips3 because we want to match
# clang's default CPU's. In the 64-bit case, we must also specify the ABI
# since the default ABI differs between gcc and clang.
# FIXME: Ideally, we would build the N32 library too.
[mips] Always use _LARGEFILE_SOURCE / _FILE_OFFSET_BITS for building MIPS 32-bit When MIPS 32-bit compiler-rt is building on 32-bit host or using 32-bit `DLLVM_HOST_TRIPLE` the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros defined by statements from the `HandleLLVMOptions.cmake`. In case of building 32-bit libraries on 64-bit host using default host triple these macros are not defined. As a result assertions check a consistency between the `struct_kernel_stat_sz` constant and the `struct_kernel_stat_sz` start to fail. To resolve this problem and enable building both 32/64-bit versions of MIPS compiler-rt libraries on 64-bit host at once always explicitly define the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros for MIPS 32-bit. llvm-svn: 360825
2019-05-16 06:27:19 +08:00
test_target_arch(mipsel "" "-mips32r2" "-mabi=32" "-D_LARGEFILE_SOURCE" "-D_FILE_OFFSET_BITS=64")
[compiler-rt][cmake][mips] Use -mabi option to select target architecture The `--target` option is rejected by GCC starting from version 7.0. It's shorter and more portable to use `mabi` option to select MIPS ABI for testing target architecture. Clang supports that starting from r343169. llvm-svn: 343182
2018-09-27 15:17:00 +08:00
test_target_arch(mips64el "" "-mips64r2" "-mabi=64")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "mips")
[mips] Always use _LARGEFILE_SOURCE / _FILE_OFFSET_BITS for building MIPS 32-bit When MIPS 32-bit compiler-rt is building on 32-bit host or using 32-bit `DLLVM_HOST_TRIPLE` the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros defined by statements from the `HandleLLVMOptions.cmake`. In case of building 32-bit libraries on 64-bit host using default host triple these macros are not defined. As a result assertions check a consistency between the `struct_kernel_stat_sz` constant and the `struct_kernel_stat_sz` start to fail. To resolve this problem and enable building both 32/64-bit versions of MIPS compiler-rt libraries on 64-bit host at once always explicitly define the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros for MIPS 32-bit. llvm-svn: 360825
2019-05-16 06:27:19 +08:00
test_target_arch(mips "" "-mips32r2" "-mabi=32" "-D_LARGEFILE_SOURCE" "-D_FILE_OFFSET_BITS=64")
[compiler-rt][cmake][mips] Use -mabi option to select target architecture The `--target` option is rejected by GCC starting from version 7.0. It's shorter and more portable to use `mabi` option to select MIPS ABI for testing target architecture. Clang supports that starting from r343169. llvm-svn: 343182
2018-09-27 15:17:00 +08:00
test_target_arch(mips64 "" "-mips64r2" "-mabi=64")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "arm")
builtins: windows has only one flavour on ARM Windows on ARM is a hard-float only environment. Don't try to build two copies of the same library. llvm-svn: 277834
2016-08-06 00:53:05 +08:00
if(WIN32)
test_target_arch(arm "" "" "")
else()
test_target_arch(arm "" "-march=armv7-a" "-mfloat-abi=soft")
test_target_arch(armhf "" "-march=armv7-a" "-mfloat-abi=hard")
[Builtin] [ARM] Update CMake to support the build of armv6m 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
2017-01-20 02:46:11 +08:00
test_target_arch(armv6m "" "-march=armv6m" "-mfloat-abi=soft")
builtins: windows has only one flavour on ARM Windows on ARM is a hard-float only environment. Don't try to build two copies of the same library. llvm-svn: 277834
2016-08-06 00:53:05 +08:00
endif()
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "aarch32")
test_target_arch(aarch32 "" "-march=armv8-a")
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "aarch64")
test_target_arch(aarch64 "" "-march=armv8-a")
[PATCH] [compiler-rt, RISCV] Support builtins for RISC-V Summary: Support builtins for RISC-V, RV32 and RV64. Reviewers: asb, apazos, mgrang Differential Revision: https://reviews.llvm.org/D42958 llvm-svn: 326420
2018-03-01 15:47:27 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "riscv32")
test_target_arch(riscv32 "" "")
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "riscv64")
test_target_arch(riscv64 "" "")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "wasm32")
test_target_arch(wasm32 "" "--target=wasm32-unknown-unknown")
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "wasm64")
test_target_arch(wasm64 "" "--target=wasm64-unknown-unknown")
[VE] Dynamic stack allocation 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
2020-05-27 15:39:39 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "ve")
test_target_arch(ve "__ve__" "--target=ve-unknown-none")
[CMake] Support platform building builtins without a full toolchain 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
2016-05-10 05:45:52 +08:00
endif()
set(COMPILER_RT_OS_SUFFIX "")
endif()
endmacro()