Building clang/llvm as a debug build results in TOC overflow even when
using large code model on AIX. This review updates the
llvm/cmake/modules/HandleLLVMOptions.cmake file to use large glink code
in addition to building as a large code model.
Differential Revision: https://reviews.llvm.org/D151733
This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true automatically builds LLVM libc in overlay mode and links all
generated executables against the libc overlay. This is intended to
somewhat mirror the LLVM_ENABLE_LIBCXX flag.
Differential Revision: https://reviews.llvm.org/D151013
In CMake, "TARGET" is a special keyword. But it's also an LLVM component, which
means downstreams may request "target" or "TARGET" from CMake. Quote such input
so "TARGET" is interpreted as a string rather than a keyword.
This is a followup to 75a0502fe0053c72b57b61143a55600814d931fd (D150884).
Fixes Meson's test suite and an issue which manifested identically to #61436
but appears to have been a slightly different problem.
Bug: https://github.com/mesonbuild/meson/issues/11642
Bug: https://github.com/llvm/llvm-project/issues/61436
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D152121
This reverts commit 39aa0f5c434b463520ac39a8dbe933ee8c4c5ea7.
This is missing the new GetClangResourceDir.cmake that is being included,
so all clang builds are broken.
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4".
When building [latest `iovisor/bcc`](1ea0390725), `cmake` complains about a change in the behavior of operator `IN_LIST`:
```console
CMake Warning (dev) at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
if given arguments:
"engine" "IN_LIST" "link_components"
Unknown arguments specified
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
```
This patch addresses this issue by setting the aforementioned policy in `LLVM-Config.cmake`.
Reviewed By: mgorny, thesamesam
Differential Revision: https://reviews.llvm.org/D150884
Closes: https://github.com/llvm/llvm-project/issues/61436
As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:
* System tools may not be able to handle the target format in case of
cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
of the script code.
The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.
Differential Revision: https://reviews.llvm.org/D149119
LLVM data structures like llvm::User and llvm::MDNode rely on
the value of object storage persisting beyond the lifetime of the
object (#24952). This is not standard compliant and causes a runtime
crash if LLVM is built with GCC and LTO enabled (#57740). Until
these issues are fixed, we need to disable dead store eliminations
eliminations based on object lifetime.
Bug: https://github.com/llvm/llvm-project/issues/24952
Bug: https://github.com/llvm/llvm-project/issues/57740
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
(This was originally committed as 94f7c961c78d8fdbc05898cfbbf88094de45c1ad but
I reverted it in b974991f4c4457a2104b648d9797a0ed438ecc9 to fix authorship.)
Reviewed By: MaskRay, thesamesam, nikic
Differential Revision: https://reviews.llvm.org/D150505
Signed-off-by: Sam James <sam@gentoo.org>
- It doesn't work if `ALL_FILES` has `$<TARGET_OBJECTS>` with Makefile generator.
- It was a micro-optimization in the ancient age. (introduced in rGe6bc093b42ff)
`llvm-min-tblgen` is capable of building `llvm/include/llvm`;
- `-gen-attrs`
- `-gen-directive-*`
- `-gen-intrinsics-*`
- `-gen-riscv-target-def`
`llvm-min-tblgen` is built and used only when `llvm-tblgen` is built in-tree.
This is not installed.
`llvm-tblgen` is built with complete set and may be installed.
`check-llvm` uses not `llvm-min-tblgen` but `llvm-tblgen`.
`LLVM_TABLEGEN_PROJECT` overrides the definition of `tablegen(project)`.
`LLVM_HEADERS` is used as the overridden prefix for LLVM header generators.
If `EXPORT` is not specified in `add_tablegen`, its tablegen is treated as internal.
Let `llvm-tblgen` depend on `intrinsics_gen`
Depends on D149072
Differential Revision: https://reviews.llvm.org/D146352
Since `llvm-min-tblgen` has been introduced, `llvm-min-tblgen-host`
would make more sense than `LLVM_HEADERS-tablegen-host`.
Depends on D146352
Differential Revision: https://reviews.llvm.org/D149343
To prevent race in `NATIVE`, let each action depend on preceding action.
At the moment, this is restricted only for "Visual Studio".
For example,
- `llvm-tblgen-host` depends on the target's `llvm-tblgen`.
- `clang-tblgen-host` depends on the target's `clang-tblgen` and `llvm-tblgen-host`.
This is rework for D54153.
`build_native_tool` has been introduced since D60024.
Differential Revision: https://reviews.llvm.org/D149072
When using compiler caching program like ccache, there is no point to
use them on external projects or multi-stage clang builds. As these
builds uses fresh from source code toolchain and will pollute the build
cache. If a compiler launcher is still required, a user can explicity
define `CMAKE_C_COMPILER_LAUNCHER` and `CMAKE_CXX_COMPILER_LAUNCHER` in
`CLANG_BOOTSTRAP_PASSTHROUGH` and `LLVM_EXTERNAL_PROJECT_PASSTHROUGH`
flags to enable compiler launcher in these builds.
Differential Revision: https://reviews.llvm.org/D144603
After building and installing LLVM with LibEdit as a dependency, it is
necessary to find it again when LLVM is consumed by another CMake
project, otherwise CMake will report an error about a missing target.
Note that the FindLibEdit.cmake file is in the "LLVM Common CMake
Utils" directory, outside of the LLVM sub-project source directory, so
the installed LLVMConfig.cmake relies on the user having installed the
LLVM common CMake modules or make available their own Find module.
Also note that the controlling HAVE_LIBEDIT CMake variable in
LLVMConfig.cmake.in has a different naming convention compared to
other similar variables like 'LLVM_ENABLE_TERMINFO'. Refactoring this
name would involve touching additional files and should be a follow-up
commit.
Patch By: ekilmer
Differential Revision: https://reviews.llvm.org/D147153
Recent commit 8f833f88ab modified the installation rpath and did not set `BUILD_WITH_INSTALL_RPATH` correctly on AIX, which led to installation failures on AIX. This patch sets `BUILD_WITH_INSTALL_RPATH` on AIX to fix the installation failures.
Reviewed By: buttaface, daltenty
Differential Revision: https://reviews.llvm.org/D148866
If any LLVM subprojects are built separately, the LLVM build directory
LLVM_LIBRARY_DIR is added to both the build and install runpaths in
llvm_setup_rpath(), which is incorrect when installed. Separate the
build and install runpaths on ELF platforms and finally remove the
incorrect call to this function for compiler-rt, as previously attempted
in 21c008d5a5b. That prior attempt was reverted in 959dbd1761c, where it
was said to break the build on macOS and Windows, so I made sure to keep
those platforms the same.
Two examples of incorrect runpaths that are currently added, one from
the latest LLVM 16 toolchain for linux x86_64:
> readelf -d clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.*so | ag "File:|runpath"
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.dyndd.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan_aliases.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.memprof.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.scudo_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.tsan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_minimal.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
Another is in the Swift toolchain, which builds lldb separately:
> readelf -d swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/{bin/lldb*,lib/liblldb.so}|ag "File:|runpath"
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-argdumper
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-server
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/lib/liblldb.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib:/home/build-user/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux:$ORIGIN/../lib/swift/linux]
This patch should fix this problem of absolute paths from the build host
leaking out into the toolchain's runpaths.
Differential revision: https://reviews.llvm.org/D146918
V2: Fix cmake error when -DLLVM_APPEND_VC_REV=OFF
Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.
Provide options to pass in repo and revision info from cmake.
```
cmake \
-DCLANG_VC_REPOSITORY=abc://repo.url.com \
-DCLANG_VC_REVISION=abcd1234 \
...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.
Differential Revision: https://reviews.llvm.org/D148262
Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.
Provide options to pass in repo and revision info from cmake.
```
cmake \
-DCLANG_VC_REPOSITORY=abc://repo.url.com \
-DCLANG_VC_REVISION=abcd1234 \
...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.
Differential Revision: https://reviews.llvm.org/D148262
When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.
The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.
LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.
In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.
The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.
Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.
This fixes
https://github.com/llvm/llvm-project/issues/60784.
Differential Revision: https://reviews.llvm.org/D146666
When the runtime dir path includes whitespace (ex. when it's installed
under "Program Files" on Windows), the lack of quotes causes the linker
to interpret the path as one or more arguments. None of these path
fragments exist, so the link fails.
Differential Revision: https://reviews.llvm.org/D145827
The change to potentially use symlinks on Windows was added in
https://reviews.llvm.org/D99170.
LLVM_USE_SYMLINKS was added more recently in
https://reviews.llvm.org/D135578 and allows specifying at configure time
whether or not symlinks should be created. The benefit of using this
option is it allows building the package on a symlink-capable Windows
machine with symlinks disabled so that the resulting package can be used
on a Windows machine that doesn't support symlinks.
Differential Revision: https://reviews.llvm.org/D145443
In D61448 the cmake option `LLVM_ENABLE_UNWIND_TABLES` was added.
Despite the name suggesting that the option enables unwind tables, that
patch only uses it to disable them. That makes a difference for
architectures where unwind tables aren't enabled by default. The lack of
unwind tables impacts backtraces and the current handling of the option
doesn't allow enabling them. This patch makes an ON value of
`LLVM_ENABLE_UNWIND_TABLES` actually enable unwind tables.
Differential Revision: https://reviews.llvm.org/D144178
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
The last non-partial-specified target can collect and check source files.
Case A:
llvm_add_library(foo PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(bar PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(baz ...)
baz checks source files in foo, bar, and baz.
Case B:
llvm_add_library(hoge PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(fuga PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(piyo PARTIAL_SOURCES_INTENDED ...)
llvm_check_source_file_list() # Explicitly checks sources in hoge, fuga, and piyo.
Differential Revision: https://reviews.llvm.org/D142256
Follow-up to https://reviews.llvm.org/D142279 for also enabling `libc++` assertions.
This is particularly useful to recover the assertion checks we had with `llvm::Optional`, before moving to `std::optional`.
Differential Revision: https://reviews.llvm.org/D143612
This reverts commit 16e1a49441c51817697138437d8db2c15bc19cb4, essentially reapplying 12d8e7c6ade55bba241259312e3e4bdcf6aeab81. The build bot where this caused issues is supposed to be updated now: https://reviews.llvm.org/D135128#4108588
On my machine this showed no new failures in check-llvm and increased
the testing time from 138 to 142 seconds, for a Release build with
assertions enabled.
Differential Revision: https://reviews.llvm.org/D142279
This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.
Differential Revision: https://reviews.llvm.org/D141738
The LLVM runtime build is used to bootstrap projects with the built LLVM
toolchain. This effectively re-runs CMake with the current build
directory. One problem is that this passes every common CMake variable
to the projects individually, some of which are not necessarily used.
This patch suppresses the unused variable warnings for the runtimes.
The standard CMake invocation should still be able to print out the
unused variables so it should not impact code quality.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D143199
cmake_push_check_state and cmake_pop_check_state doesn't save and
restore CMAKE_EXE_LINKER_FLAGS so we need to do it manually.
Differential Revision: https://reviews.llvm.org/D143088
This change force us to use the top-level CMake's detected tools. We
need to do this as a temporary workaround as when using CMake
versions >= 3.22 we'll pickup the built llvm-ranlib by default if it's
in the path (which it is when doing a sub build via
llvm_ExternalProject_Add for the runtimes).
llvm-ranlib runs into problems on AIX due to missing 64-bit
functionality to be added by
https://reviews.llvm.org/D142479 and https://reviews.llvm.org/D142660.
Once those patches land, this can be reverted.
Differential Revision: https://reviews.llvm.org/D142727
