Commit Graph

51 Commits

Author SHA1 Message Date
Christopher Di Bella ef0b20d8e8 [runtimes] adds llvm-libgcc to the list of runtimes to be sorted
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
2022-06-30 23:50:24 +00:00
James Nagurne f4fdc4f4d9 Restore missing runtimes-test-depends target that causes build failures when 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
2022-06-13 15:47:38 -05:00
Petr Hosek 186a13f647 [CMake][libcxx] Use target_include_directories for libc++ headers
This is the idiomatic way to handle include directories in CMake.

Differential Revision: https://reviews.llvm.org/D122614
2022-06-12 22:17:50 +00:00
Louis Dionne 06400a0142 [runtimes] Generalize how we reorder projects
This way, we could use it for LLVM_ENABLE_PROJECTS too if desired.

Differential Revision: https://reviews.llvm.org/D125121
2022-05-16 08:55:32 -04:00
Martin Storsjö 4169b5251f [runtimes] [CMake] Fix checks for -Werror when building with incomplete 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
2022-05-13 00:29:51 +03:00
Petr Hosek 83e07916ff Revert "[CMake][libcxx] Use target_include_directories for libc++ headers"
This reverts commit 203455c85a since
it breaks the OpenMP builders for AMDGPU.
2022-05-06 22:20:06 -07:00
Petr Hosek 203455c85a [CMake][libcxx] Use target_include_directories for libc++ headers
This is the idiomatic way to handle include directories in CMake.

Differential Revision: https://reviews.llvm.org/D122614
2022-05-06 14:06:25 -07:00
Louis Dionne 7b04bf9d6f [runtimes] Always configure libc++abi before libc++
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
2022-05-06 15:44:25 -04:00
Sam McCall 7cc8377f2c Generalize "check-all" umbrella targets, use for check-clang-tools
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
2022-05-06 12:30:49 +02:00
Martin Storsjö 9a7339c997 [runtimes] [CMake] Rename a cmake variable missed in b3df14b6c9
This was missed as this check only is executed if linking doesn't
work without it.
2022-04-25 11:22:38 +03:00
Petr Hosek b3df14b6c9 [runtimes] [CMake] Unify variable names
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
2022-04-24 13:06:36 +03:00
Petr Hosek f39a971d82 [CMake] Include runtimes test suites in check-all
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
2022-03-10 10:18:37 -08:00
Christopher Di Bella c5a20b5182 [llvm-libgcc] initial commit
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
2022-02-16 17:06:45 +00:00
Nico Weber 90ca7b3bca [runtimes] rewrap a comment to 80 columns 2022-02-10 20:57:13 -05:00
John Ericson 7017e6c9cf [cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for 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
2022-01-29 06:07:24 +00:00
Petr Hosek 10e5c513b5 Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm"
This reverts commit 4af11272f5.
2022-01-21 09:53:14 -08:00
John Ericson 4af11272f5 [cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs 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
2022-01-20 21:18:42 +00:00
John Ericson 949bbd0a68 [CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity
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
2022-01-03 20:55:44 +00:00
Martin Storsjö 529a79302b Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Since the previous attempt, this no longer uses
llvm_enable_language_nolink (and thus doesn't set
CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler
sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
during compiler sanity checks makes cmake not learn about some
aspects of the compiler, which can make further find_library or
find_package fail. This caused OpenMP to not detect libelf and libffi,
disabling some OpenMP target plugins.

Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES
when building in a configuration with an incomplete toolchain.

Differential Revision: https://reviews.llvm.org/D113253
2021-12-09 21:38:14 +02:00
Martin Storsjö 62cff45d76 Revert "Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind"
This reverts commit 317dc31e53.

After that change, OpenMP doesn't find dependencies in the host
system (it fails do find e.g. /usr/lib/x86_64-linux-gnu/libelf.so
which it found before), which causes some OpenMP target offloading
plugins to not be found. This doesn't break the build, but just
causes the AMDGPU OpenMP target plugin to be omitted. See
https://reviews.llvm.org/D113253#3181934 for the report of this
issue.
2021-12-09 12:56:57 +02:00
Mircea Trofin 5dda2efde5 Re-Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'"
This reverts commit b2fbd45d23. D114922
fixed the reason of the 2nd revert.

This patch also re-applies 39e9f5d368.

Differential Revision: https://reviews.llvm.org/D112012
2021-12-07 17:10:41 -08:00
Martin Storsjö 317dc31e53 Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Reapplying this after
db32c4f456, which should fix the issues
that were reported last time this was applied.

Differential Revision: https://reviews.llvm.org/D113253
2021-12-08 00:32:40 +02:00
Louis Dionne 774f7832fb [runtimes] Do not force -stdlib=libc++ on Apple platforms
It is pointless to specify -stdlib=libc++ on Apple platforms since
that is the default anyway.

Differential Revision: https://reviews.llvm.org/D114283
2021-11-22 12:05:09 -05:00
Martin Storsjö efbe9ae23f Revert "[runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind"
This reverts commit 7c3d19ab7b.

This commit was reported as causing build problems for the amdgpu
buildbot in https://reviews.llvm.org/D113253#3137097.
2021-11-17 12:50:33 +02:00
Mircea Trofin 663693f3f7 [libc] Fix incorrect revert of 1ee3205
The revert, b2fbd45d23, incorrectly
re-introduced a few lines removed in 7c3d19ab7b
2021-11-16 23:13:16 -08:00
Mircea Trofin b2fbd45d23 Revert "Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'"""
This reverts commit 1ee32055ea.

We hit additional bot failures; in particular, Fuchsia's seems to be
related to how CMakeLists are ingested, see https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8830380874445931681/overview
2021-11-16 16:35:06 -08:00
Martin Storsjö 7c3d19ab7b [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:

Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.

Differential Revision: https://reviews.llvm.org/D113253
2021-11-16 23:04:06 +02:00
Louis Dionne 86d866f2f6 [runtimes] Fix incorrect comment about the purpose of LLVM_DEFAULT_TARGET_TRIPLE
5beec6fb04 added LLVM_DEFAULT_TARGET_TRIPLE to the runtimes build with
a comment, however I believe that comment had been copied from the LLVM
build tree. In the context of the runtimes, LLVM_DEFAULT_TARGET_TRIPLE
is used to set what targets we are building for, not the target for which
we "generate code".

Differential Revision: https://reviews.llvm.org/D114007
2021-11-16 16:01:24 -05:00
Mircea Trofin 1ee32055ea Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'""
This reverts commit e7568b68da and relands
c6f7b720ec.

The culprit was: missed that libc also had a dependency on one of the
copies of `google-benchmark`

Also opportunistically fixed indentation from prev. change.

Differential Revision: https://reviews.llvm.org/D112012
2021-11-16 10:33:31 -08:00
Mircea Trofin e7568b68da Revert "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'"
This reverts commit c6f7b720ec.

Some buildbots are failing, will investigate and reland.
Example:
  https://lab.llvm.org/buildbot#builders/138/builds/14067
  https://lab.llvm.org/buildbot#builders/73/builds/20159
2021-11-16 09:28:50 -08:00
Mircea Trofin c6f7b720ec [benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'
under third-party

This change:
- moves the libcxx copy of `google/benchmark` to
`third-party/benchmkark`
- points the 2 uses of the library (libcxx and llvm/utils) to this copy

We picked the licxx copy because it is the most up to date.

Differential Revision: https://reviews.llvm.org/D112012
2021-11-16 09:16:11 -08:00
David Spickett 5beec6fb04 [libcxxabi/runtimes] Set LLVM_HOST_TRIPLE in runtimes build
This allows tests to tell if they're running natively.

Those tests are libcxxabi/test/native/arm-linux-eabi.
Which were running on Linaro's bots but became unsupported
when we switched to the runtimes build.

Reviewed By: #libc_abi, phosek

Differential Revision: https://reviews.llvm.org/D113663
2021-11-16 16:30:17 +00:00
Louis Dionne 7a801138f8 [runtimes] Make sure LLVM_LIT_ARGS is set before including individual runtimes
Otherwise, the individual `check-cxx`, `check-cxxabi` and similar targets
will not know about `LLVM_LIT_ARGS`, and we'll end up running lit without
any argument.

Differential Revision: https://reviews.llvm.org/D112035
2021-10-19 08:21:29 -04:00
Louis Dionne 79175f336c [runtimes] Use the new "runtimes" build by default and deprecate other builds
This commit makes the new "runtimes" build (with <monorepo>/runtimes as
the root of the CMake invocation) the default way of building libc++.
The other supported way of building libc++ is the "bootstrapping" build,
where `<monorepo>/llvm` is used as the root of the CMake invocation.

All other ways of building libc++ are deprecated effective immediately.
There should be no use-case for building libc++ that isn't supported by
one of these two builds, and the two new builds work on all environments
and are lightweight. They will also make it possible to greatly simplify
the build infrastructure of the runtimes, which is currently way too
convoluted.

Differential Revision: https://reviews.llvm.org/D111356
2021-10-18 13:50:26 -04:00
Martin Storsjö a785e5c395 [runtimes] Set a default value for LLVM_LIT_ARGS
This matches the value used in
libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake.

Differential Revision: https://reviews.llvm.org/D110987
2021-10-05 10:45:44 +03:00
Martin Storsjö 565d45541f [libcxx] Add a CI configuration for standalone building in llvm-project/runtimes
Generate the llvm-lit script in runtimes/CmakeFiles.txt unless invoked
from llvm/runtimes.

Differential Revision: https://reviews.llvm.org/D109593
2021-09-29 21:37:28 +03:00
Alfonso Gregory a2c319fdc6 [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D107717
2021-09-16 18:29:57 +02:00
Martin Storsjö 125e8ef10b [runtimes] Check whether -nostdinc++ and -nostdlib++ are supported
Don't blindly assume they're supported - GCC doesn't support -nostdlib++.

The llvm-project/runtimes directory is supposed to allow building the
runtimes standalone from a newly built Clang, and thus should allow
building with other compilers too.

Differential Revision: https://reviews.llvm.org/D109719
2021-09-14 13:42:51 +03:00
Martin Storsjö 5b007f2c94 [runtimes] Calculate the path to the llvm directory without the LLVM cmake package
If building by pointing cmake directly at the llvm-project/runtimes
directory, the llvm cmake package files (that provide e.g.
LLVM_BUILD_MAIN_SRC_DIR) aren't necessarily available. Instead just
use a path relative to the current source dir.

Differential Revision: https://reviews.llvm.org/D109717
2021-09-14 11:04:25 +03:00
Martin Storsjö 61f22f70ca [runtimes] Initialize LLVM_DEFAULT_TARGET_TRIPLE if not set by the caller
Differential Revision: https://reviews.llvm.org/D109716
2021-09-14 11:04:23 +03:00
Petr Hosek baf1444929 [CMake] Use NOT instead of STREQUAL
`<var> STREQUAL ""` fails when `<var>` is unset which can be the
case when using runtimes as top-level build. Use `NOT` instead.

Differential Revision: https://reviews.llvm.org/D109570
2021-09-10 01:32:46 -07:00
Martin Storsjö a3870e8ab1 Reapply [runtimes] Set more paths when building runtimes standalone
These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

Fixed since previous attempt: Don't check if the runtimes directory
is the root of the CMake invocation; when the main LLVM CMake
build builds runtimes, it does invoke a sub-CMake with this directory
as the root too, just as if manually invoking CMake at the runtimes
directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and
whether find_package(LLVM) succeeded or not.

Differential Revision: https://reviews.llvm.org/D107895
2021-09-09 15:30:42 +03:00
Leonard Chan d96e0c5388 Revert "[runtimes] Set more paths when building runtimes standalone"
This reverts commit 407e07aa67.

Reverting since this seems to break OpenMP builds and our clang
builders. See thread on https://reviews.llvm.org/D107895.
2021-09-08 18:31:10 -07:00
Martin Storsjö 407e07aa67 [runtimes] Set more paths when building runtimes standalone
These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

Differential Revision: https://reviews.llvm.org/D107895
2021-09-09 00:01:38 +03:00
Siva Chandra d0a71c6ee6 [runtimes] Add the libc project to the list of runtimes.
This is possible as the default libc build now works under runtimes build.

Differential Revision: https://reviews.llvm.org/D99101
2021-03-23 17:33:03 +00:00
Petr Hosek 61a792b39b [CMake] Rename RUNTIMES_BUILD to LLVM_RUNTIMES_BUILD
This avoid potential conflict with other internal variables.

Differential Revision: https://reviews.llvm.org/D97838
2021-03-03 10:58:51 -08:00
Petr Hosek 6e3946c9f5 [runtimes] Use standalone build only for compiler-rt
compiler-rt needs to use standalone build because of the assumptions
made by its build, but other runtimes can use non-standalone build.

Differential Revision: https://reviews.llvm.org/D97575
2021-03-03 00:06:20 -08:00
Petr Hosek b3ac90da1d Revert "[runtimes] Use standalone build only for compiler-rt"
This reverts commit 4e421b2323 as this
seemed to have broke Python 3 executable detection on some builders.
2021-03-02 16:59:32 -08:00
Petr Hosek 4e421b2323 [runtimes] Use standalone build only for compiler-rt
compiler-rt needs to use standalone build because of the assumptions
made by its build, but other runtimes can use non-standalone build.

Differential Revision: https://reviews.llvm.org/D97575
2021-03-02 16:21:35 -08:00
Reid Kleckner 98c89ccfbd [MSVC] Don't add -nostdinc++ -isystem to runtimes builds
If the host compiler is MSVC or clang-cl, then the compiler used to
buidl the runtimes will be clang-cl, and it doesn't support either of
those flags.

Worse, because -isystem is a space separated flag, it causes all cmake
try_compile tests to fail, so none of the -Wno-* flags make it to the
compiler in libcxx. I noticed that we weren't passing
-Wno-user-defined-literals to clang-cl and were getting warnings in the
build, and this fixes that for me.

Differential Revision: https://reviews.llvm.org/D94817
2021-01-15 13:22:07 -08:00