This adds multilibs for Fuchsia that is built with the relative vtables ABI,
one with and another without exceptions.
Differential Revision: https://reviews.llvm.org/D85576
Since RPATH initialization was disabled for the runtime libraries to
avoid overwriting RPATH unconditionally we need to explicity set up it
for the Win to Arm Linux cross builds.
See some details here: https://reviews.llvm.org/D91099
Use LLVM/utils/remote-exec.py to run compiler-rt tests remotely on the target.
Reviewed By: vvereschaka
Differential Revision: https://reviews.llvm.org/D90054
Since 9b40ee8eb0, new/delete must be requested explicitly during the
CMake configuration if one wants these definitions to appear in libc++.
Differential Revision: https://reviews.llvm.org/D89793
Have the build work out of the box by forcing an LLD build.
That way, we don't require an external LTO-aware linker,
as we build one.
Also remove reference to the seemingly dead builder.
Differential Revision: https://reviews.llvm.org/D88990
We prefer autodetection here to avoid persisting this configuration
in the generated __config header which is shared across targets.
Differential Revision: https://reviews.llvm.org/D88694
Instead of using CLANG_ENABLE_STATIC_ANALYZER for use of the
static analyzer in both clang and clang-tidy, add a second
toggle CLANG_TIDY_ENABLE_STATIC_ANALYZER.
This allows enabling the static analyzer in clang-tidy while
disabling it in clang.
Differential Revison: https://reviews.llvm.org/D87118
This patch adds the missing information to the LF_BUILDINFO record, which allows for rebuilding a .CPP without any external dependency but the .OBJ itself (other than the compiler).
Some external tools that we are using (Recode, Live++) are extracting the information to reproduce a build without any knowledge of the build system. The LF_BUILDINFO stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the TU, and the full CC1 command line. The command line needs to be freestanding (not depend on any environment variables). In the same way, MSVC doesn't store the provided command-line, but an expanded version (somehow their equivalent of CC1) which is also freestanding.
For more information see PR36198 and D43002.
Differential Revision: https://reviews.llvm.org/D80833
This change adds the necessary flags for building the full Fuchsia
toolchain on Windows with MSVC.
Differential Revision: https://reviews.llvm.org/D73810
We make assumptions about what projects and runtimes are enabled
when configuring our toolchain build, so we should enable those in
the cache file as well rather than relying on those being set
externally.
Differential Revision: https://reviews.llvm.org/D81514
If a client code wants to consume clang libraries, it needs to know
CLANG_LINK_CLANG_DYLIB value in order to decide whether to use the DYLIB or
individual components.
Differential Revision: https://reviews.llvm.org/D82291
In order to support the libcxx new format changes SSHExecutor was
replaced with ssh.py script in the following way:
LIBxxx_EXECUTOR="<llvm-root>/libcxx/utils/ssh.py --host <username>@<host>"
See 96e6cbbf94 commit for details.
The in-process CC1 currently doesn't interoperate with the macOS crash analytics,
which we would like to keep enabled for Apple clang. This commit restores the
out-of-process CC1 to the Apple clang CMake configuration for now.
Differential Revision: https://reviews.llvm.org/D80849
gLinux started shipping incompatible versions of Z3, which can lead to a
missing `z3.h` header when building the Z3 solver locally. This patch
disables the Z3 solver when building a clang toolchain for Fuchsia.
Differential Revision: https://reviews.llvm.org/D79974
f8990feb12 enabled installing PIC version of both libclang.a and
libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC
build when LLVM_ENABLE_PIC=OFF with the following error:
```
CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
target_compile_definitions called with non-compilable target type
```
This is because as the code loops through ${name} and ${name}_static, it
introduced a side effect, which is adding an empty libclang_static to
targets. Later target_compile_definitions is called on libclang_static.
That function requires that target must have been created by a command
such as add_executable() or add_library(), so it crashed.
The solution is to not naively loop through both libclang and
libclang_static, but only the ones that are actually added by
llvm_add_library(). Here's the library build type to library target name
mapping:
| SHARED only | libclang |
| STATIC only | libclang |
| SHARED and STATIC | libclang and libclang_static |
So only when SHARED and STATIC are both set should we loop through two
targets. Explicitly parse the STATIC argument and set the list
accordingly.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D79059
This broke builds configured with
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=clang' '-DLLVM_TARGETS_TO_BUILD=X86' -DLLVM_ENABLE_PIC=OFF ../llvm
CMake Error at
/b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123
(target_compile_definitions):
target_compile_definitions called with non-compilable target type
This reverts commit f8990feb12.
When LIBCLANG_BUILD_STATIC=ON and LLVM_ENABLE_PIC=ON, PIC version of
libclang.a and libclang.so are built as expected. However libclang.a is
not installed. Looking at the macro llvm_add_library(), when both SHARED
and STATIC are set, it renames the static library to ${name}_static and
then adds it to targets. But when add_clang_library() calls install, it
only checks if ${name} is in targets.
To work around this issue, loop through both ${name} and ${name}_static
and install both of them if they're in targets. This is still correct if
only shared or static library is built. In those cases, only ${name} is
added to targets and cmake install will generate the right install
script depending on the library's type.
Test Plan:
cmake with LIBCLANG_BUILD_STATIC=ON and then ninja install, from master
and this diff. Compare the result directory trees. Confirm that only
difference is the added libclang.a.
Differential Revision: https://reviews.llvm.org/D78534
While we don't support 32-bit architectures in Fuchsia, these are needed
in the early boot phase on x86, so we build just these to satisfy that
use case.
Differential Revision: https://reviews.llvm.org/D78687
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths. This
becomes unwieldy as there are more users for which these paths are
insufficient. For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen. As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().
I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful. There are several users in clang which apparently
don't have the current directory as an include_directories(). This could
be considered separately.
The new version of this path uses list APPEND rather than list TRANSFORM,
in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then
we can use list TRANSFORM instead.
Differential Revision: https://reviews.llvm.org/D77156
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths. This
becomes unwieldy as there are more users for which these paths are
insufficient. For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen. As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().
I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful. There are several users in clang which apparently
don't have the current directory as an include_directories(). This could
be considered separately.
Differential Revision: https://reviews.llvm.org/D77156
Summary: Now that D72687 has landed, we can enable this setting in our cache file.
Reviewers: vvereschaka
Reviewed By: vvereschaka
Subscribers: mgorny, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76774
This makes toolchain independent of the path it was built in by
rewriting all absolute paths embedded in sources and debug info
into relative ones.
Differential Revision: https://reviews.llvm.org/D76189
Summary:
D69169, which was necessary for running libc++ tests on remote host, got reverted. I couldn't think of a less invasive way to achieve this behavior but specify libc++abi paths in our cache file.
Reviewers: vvereschaka, aorlov, andreil99, EricWF
Reviewed By: vvereschaka
Subscribers: mgorny, kristof.beyls, ldionne, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74347
It was reverted in 35367e06b8
because it broke the buildbot due to missing libc++abi headers.
https://reviews.llvm.org/D75991 improves the diagnostics, so I hope
the build log will be more informative.
Summary:
D69169, which was necessary for running libc++ tests on remote host, got reverted. I couldn't think of a less invasive way to achieve this behavior but specify libc++abi paths in our cache file.
Reviewers: vvereschaka, aorlov, andreil99, EricWF
Reviewed By: vvereschaka
Subscribers: mgorny, kristof.beyls, ldionne, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74347
The in-process cc1 currently breaks Goma client and therefore prevents
the use of tip-of-tree Clang with Goma, so we disable the in-process cc1
in our toolchain until this issue is resolved.
Summary:
Now that D71894 has landed, we're able to run libc++abi tests remotely.
For that we can use the same CMake command as before. The tests can be run using `ninja check-cxxabi`.
Reviewers: andreil99, vvereschaka, aorlov
Reviewed By: vvereschaka, aorlov
Subscribers: mgorny, kristof.beyls, ldionne, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72459
Roland McGrath