summaryrefslogtreecommitdiff
path: root/runtimes
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Nico Weber2023-05-171-1/+8
| | | | | | | | | | | | | | This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c. Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards. Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C" This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559. Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump" This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
* Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever2023-05-131-8/+1
| | | | | | The owner of the last two failing buildbots updated CMake. This reverts commit e8e8707b4aa6e4cc04c0cffb2de01d2de71165fc.
* Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever2023-05-061-1/+8
| | | | | | Unfortunatly not all buildbots are updated. This reverts commit ffb807ab5375b3f78df198dc5d4302b3b552242f.
* Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever2023-05-061-8/+1
| | | | | | All build bots should be updated now. This reverts commit 44d38022ab29a3156349602733b3459df5beef93.
* Revert "Revert "Revert "[CMake] Bumps minimum version to 3.20.0."""Mark de Wever2023-04-151-1/+8
| | | | | | This reverts commit 1ef4c3c859728008cf707cad8d67f45ae5070ae1. Two buildbots still haven't been updated.
* Revert "Revert "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever2023-04-151-8/+1
| | | | | | This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade. Reland to see whether CIs are updated.
* Revert "[CMake] Unify llvm_check_linker_flag and ↵Petr Hosek2023-03-281-4/+1
| | | | | | llvm_check_compiler_linker_flag" This reverts commit 55e65ad876e3ac0b1cb0410a5cce3554c009af65.
* [runtimes][CMake] Drop the check to see if linker worksPetr Hosek2023-03-281-30/+32
| | | | | | This isn't needed anymore. Differential Revision: https://reviews.llvm.org/D144440
* [CMake] Unify llvm_check_linker_flag and llvm_check_compiler_linker_flagPetr Hosek2023-03-281-1/+4
| | | | | | | These will be replaced by CMake's check_linker_flag once we update the minimum CMake version 3.20. Differential Revision: https://reviews.llvm.org/D145716
* [runtimes] Don't use -Wall on clang-cl buildsNikolas Klauser2023-03-191-1/+0
| | | | | | | | `-Wall` on clang-cl is equivalent to `-Weverything` on clang. We already add the correct warning flag depending whether we are in an MSVC-like environment, so just remove it from the list of flags that get passed unconditionally. Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D146378
* Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever2023-03-181-1/+8
| | | | | | This reverts commit a72165e5df59032cdd54dcb18155f2630d73abd1. Some buildbots have not been updated yet.
* Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever2023-03-181-8/+1
| | | | | | This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade. Test whether all CI runners are updated.
* [runtimes] Synchronize warnings flags between libc++/libc++abi/libunwindNikolas Klauser2023-03-171-0/+78
| | | | | | | | | | This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind. Reviewed By: ldionne, #libunwind, #libc, #libc_abi Spies: mikhail.ramalho, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D144252
* Revert "[CMake] Bumps minimum version to 3.20.0."Mark de Wever2023-03-041-1/+8
| | | | | | | Some build bots have not been updated to the new minimal CMake version. Reverting for now and ping the buildbot owners. This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
* [CMake] Bumps minimum version to 3.20.0.Mark de Wever2023-03-041-8/+1
| | | | | | | | | | | | | | This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi Differential Revision: https://reviews.llvm.org/D144509
* Revert "[CMake] Unify llvm_check_linker_flag and ↵Petr Hosek2023-02-221-3/+3
| | | | | | | llvm_check_compiler_linker_flag" This reverts commit efae3174f09560353fb0f3d528bcbffe060d5438 since it broke the standalone Flang build.
* [CMake] Unify llvm_check_linker_flag and llvm_check_compiler_linker_flagPetr Hosek2023-02-221-3/+3
| | | | | | | | | | | These have the same purposes but two different implementations. llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects flags used both for compilation and linking which is problematic because some flags may be link-only and trigger unused argument warning when set during compilation. llvm_check_linker_flag does not have this issue so we chose it as the prevailaing implementation. Differential Revision: https://reviews.llvm.org/D143052
* [runtimes] Move common functions from ↵Nikolas Klauser2023-02-211-0/+113
| | | | | | | | | | Handle{Libcxx,Libcxxabi,Libunwind}Flags.cmake to runtimes/cmake/Modules/HandleFlags.cmake Reviewed By: phosek, #libunwind, #libc, #libc_abi Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D144395
* [CMake] Setting the LLVM_TARGET_TRIPLE macro based on the ↵Nicole Rabjohn2022-12-131-0/+3
| | | | | | | | | | | LLVM_DEFAULT_TARGET_TRIPLE After D137870, LLVM_TARGET_TRIPLE is no longer defined on the runtime path into compiler-rt. This patch creates a common block of code to set LLVM_TARGET_TRIPLE equal to the default for both the llvm- and runtime- paths. Differential Revision: https://reviews.llvm.org/D138864
* [CMake] Warn when the version is older than 3.20.0.Mark de Wever2022-12-111-0/+7
| | | | | | | | | | | | This is a preparation to require CMake 3.20.0 after LLVM 16 has been released. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Reviewed By: #libc_vendors, MaskRay, ChuanqiXu, to268, thieta, stellaraccident, ldionne, #libc, #libc_abi, phosek Differential Revision: https://reviews.llvm.org/D137724
* Revert "[CMake] Use LLVM_TARGET_TRIPLE in runtimes"Leonard Chan2022-12-051-2/+2
| | | | | | | | | | | | | | This reverts commit bec8a372fc0db95852748691c0f4933044026b25. This causes many of these errors to appear when rebuilding runtimes part of fuchsia's toolchain: ld.lld: error: /usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o) is incompatible with elf64-x86-64 This can be reproduced by making a complete toolchain, saving any source file with no changes, then rerunning ninja distribution.
* [runtimes] Fix runtimes-test-dependsShoaib Meenai2022-11-301-1/+6
| | | | | | The dependency list is stored in a global property, so we need to fetch it to a variable before using that variable. We also need to add the list contents as dependencies correctly.
* [runtimes] Name stripped install targets consistentlyShoaib Meenai2022-11-301-3/+0
| | | | | | | | | | | | We were previously naming sub-component stripped install targets as `install-${component}-stripped-${triple}`, whereas everywhere else names them `install-${component}-${triple}-stripped`. This inconsistency would cause issues when LLVM_RUNTIME_DISTRIBUTION_COMPONENTS contained a sub-component (which I'm addding support for next). Reviewed By: phosek, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D138965
* [CMake] Use LLVM_TARGET_TRIPLE in runtimesPetr Hosek2022-11-291-2/+2
| | | | | | | | This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default, but using a separate variable allows additional normalization to be performed if needed. Differential Revision: https://reviews.llvm.org/D137451
* [CMake][compiler-rt] Don't load LLVM config in the runtimes buildPetr Hosek2022-11-151-0/+1
| | | | | | | LLVM runtimes build already loads the LLVM config and sets all appropriate variables, no need to do it again. Differential Revision: https://reviews.llvm.org/D137870
* [runtimes] Use a response file for runtimes test suitesPetr Hosek2022-10-122-12/+6
| | | | | | | | | | | | | We don't know which test suites are going to be included by runtimes builds so we cannot include those before running the sub-build, but that's not possible during the LLVM build configuration. We instead use a response file that's populated by the runtimes build as a level of indirection. This addresses the issue described in: https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788 Differential Revision: https://reviews.llvm.org/D132438
* Revert "[runtimes] Use a response file for runtimes test suites"Arthur Eubanks2022-08-292-4/+9
| | | | | | This reverts commit 992e10a3fce41255e4b11782f51d0f4b26dca14d. Breaks builds with LLVM_INCLUDE_TESTS=OFF, see comments in D132438.
* [runtimes][NFC] Colocate handling of LLVM_ENABLE_PROJECTS and ↵Louis Dionne2022-08-241-3/+3
| | | | | | | | | | | LLVM_ENABLE_RUNTIMES This will make the following patches to migrate projects off of the LLVM_ENABLE_PROJECTS build onto the LLVM_ENABLE_RUNTIMES build much easier to comprehend. This patch should be a NFC since it keeps the same set of runtimes being built by default. Differential Revision: https://reviews.llvm.org/D132478
* [runtimes] Use a response file for runtimes test suitesPetr Hosek2022-08-242-9/+4
| | | | | | | | | | | | | We don't know which test suites are going to be included by runtimes builds so we cannot include those before running the sub-build, but that's not possible during the LLVM build configuration. We instead use a response file that's populated by the runtimes build as a level of indirection. This addresses the issue described in: https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788 Differential Revision: https://reviews.llvm.org/D132438
* [compiler-rt][libunwind][runtimes] Recategorize `llvm_check_linker_flag` langsJohn Ericson2022-08-171-1/+1
| | | | | | | | | | | Done according to @phosek's comments in D117537, but not done then to separate pure refactor (that) from possible behavior change (this). Wasn't working before, but I think that was due to an issue of mismatched variable names fixed in D110005. Reviewed By: phosek, #libunwind, #libc_abi Differential Revision: https://reviews.llvm.org/D117833
* [runtimes] Add pstl to the list of default runtimes to fix the buildNikolas Klauser2022-07-221-1/+1
| | | | | | | | Reviewed By: ldionne, #libc, #libc_abi Spies: h-vetinari, sstefan1, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D129452
* [runtimes] adds llvm-libgcc to the list of runtimes to be sortedChristopher Di Bella2022-06-301-2/+3
| | | | | | | | llvm-libgcc is not a part of `LLVM_ALL_RUNTIMES` because llvm-libgcc is incompatible with an explicit libunwind and compiler-rt. This meant that it was being filtered out and not built. Differential Revision: https://reviews.llvm.org/D128568
* Restore missing runtimes-test-depends target that causes build failures when ↵James Nagurne2022-06-131-0/+4
| | | | | | | | | | | | LLVM_INCLUDE_TESTS is ON 7cc8377f removed the 'runtimes-test-depends' target in runtimes builds that is assumed to exist when using a bootstrapped runtime build. For a full analysis, see: https://discourse.llvm.org/t/looking-for-guidance-on-broken-downstream-bootstrapped-runtimes-builds/62934 Differential Revision: https://reviews.llvm.org/D127325
* [CMake][libcxx] Use target_include_directories for libc++ headersPetr Hosek2022-06-121-0/+20
| | | | | | This is the idiomatic way to handle include directories in CMake. Differential Revision: https://reviews.llvm.org/D122614
* [runtimes] Generalize how we reorder projectsLouis Dionne2022-05-161-35/+16
| | | | | | This way, we could use it for LLVM_ENABLE_PROJECTS too if desired. Differential Revision: https://reviews.llvm.org/D125121
* [runtimes] [CMake] Fix checks for -Werror when building with incomplete ↵Martin Storsjö2022-05-131-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | toolchains When we add `--unwindlib=none` during the CMake configure phase (to make CMake linking tests succeed before the unwind library has been built for the first time - when bootstrapping a cross toolchain from scratch), we add it to `CMAKE_REQUIRED_FLAGS` to make later CMake tests pass. When the option is added to `CMAKE_REQUIRED_FLAGS`, it gets added to both compilation and linking commands. When --unwindlib=none is added to the compilation command, it causes warnings (about being unused during compilation, as it only affects linking). When all CMake test compilations produce warnings, later CMake tests for `-Werror` fail. Add `--{start,end}-no-unused-arguments` around `--unwindlib=none`, if supported, to avoid unnecessary warnings due to this option. If the CMake requirement is bumped to 3.14, we could use `CMAKE_REQUIRED_LINK_OPTIONS` instead, removing the need for the `--{start,end}-no-unused-arguments` options. (However, do note that `CMAKE_REQUIRED_LINK_OPTIONS` is problematic in combination with `CMAKE_TRY_COMPILE_TARGET_TYPE` set to `STATIC_LIBRARY`; see https://gitlab.kitware.com/cmake/cmake/-/issues/23454.) Differential Revision: https://reviews.llvm.org/D124377
* Revert "[CMake][libcxx] Use target_include_directories for libc++ headers"Petr Hosek2022-05-061-11/+0
| | | | | This reverts commit 203455c85ad03325ce2d77f067f6ac953f2a32ce since it breaks the OpenMP builders for AMDGPU.
* [CMake][libcxx] Use target_include_directories for libc++ headersPetr Hosek2022-05-061-0/+11
| | | | | | This is the idiomatic way to handle include directories in CMake. Differential Revision: https://reviews.llvm.org/D122614
* [runtimes] Always configure libc++abi before libc++Louis Dionne2022-05-061-22/+22
| | | | | | | | | | That makes it possible to reuse libc++abi targets from the libc++ configuration, which is necessary to allow major CMake simplifications. As a fly-by fix, we also unify how compiler-rt ordering is handled so it matches how libc++ and libc++abi are handled (compiler-rt always ends up first). Differential Revision: https://reviews.llvm.org/D120719
* Generalize "check-all" umbrella targets, use for check-clang-toolsSam McCall2022-05-062-27/+6
| | | | | | | | | | | | | | | | | | | The mechanism behind "check-all" is recording params of add_lit_testsuite() calls in global variables LLVM_LIT_*, and then creating an extra suite with their union at the end. This avoids composing the check-* targets directly, which doesn't work well. We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*: umbrella_lit_testsuite_begin(check-foo) ... test suites here will be added to LLVM_FOO_LIT_* variables ... umbrella_lit_testsuite_end(check-foo) (This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt This patch also changes check-clang-tools to use be an umbrella test target, which means the clangd and clang-pseudo tests are included in it, along with the the other testsuites that already are (like check-clang-extra-clang-tidy). Differential Revision: https://reviews.llvm.org/D121838
* [runtimes] [CMake] Rename a cmake variable missed in ↵Martin Storsjö2022-04-251-2/+2
| | | | | | | b3df14b6c98702ce50401fd039852787373e4676 This was missed as this check only is executed if linking doesn't work without it.
* [runtimes] [CMake] Unify variable namesPetr Hosek2022-04-241-4/+4
| | | | | | | Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
* [runtimes] Detect changes to Tests.cmakePetr Hosek2022-03-181-3/+3
| | | | | | | This ensures that Tests.cmake is tracked by Ninja and any changes to this file from the subbuilds are correctly detected. Differential Revision: https://reviews.llvm.org/D121647
* [CMake] Include runtimes test suites in check-allPetr Hosek2022-03-102-0/+13
| | | | | | | | | | | | | | | | | Prior to this change, we would make check-all depend on check-runtimes which is a target that runs tests in the runtimes build. This means that the runtimes tests are going to run prior to other test suites in check-all, and if one of them fails, we won't run the other test suites at all. To address this issue, we instead collect the list of test suites and their dependencies from the runtimes subbuild, and include them in check-all, so a failure of runtimes test suite doesn't prevent other test suites from being executed. This addresses https://github.com/llvm/llvm-project/issues/54154. Differential Revision: https://reviews.llvm.org/D121276
* [llvm-libgcc] initial commitChristopher Di Bella2022-02-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
* [runtimes] rewrap a comment to 80 columnsNico Weber2022-02-101-2/+2
|
* [cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for ↵John Ericson2022-01-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | runtime libs and llvm We previously had a few varied definitions of this floating around. I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior. My compromise solution is this: - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt. - Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too. - Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision. In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work. The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and LLVM use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
* Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime ↵Petr Hosek2022-01-211-3/+3
| | | | | | libs and llvm" This reverts commit 4af11272f57a4a6fed2932e9e0857b2c1a707c51.
* [cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs ↵John Ericson2022-01-201-3/+3
| | | | | | | | | | | | | and llvm We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it. This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and llvm use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
* [CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarityJohn Ericson2022-01-031-2/+4
| | | | | | | | | | | | | | | | In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
View Lorry Controller Status