When the top-level CMake invocation has `CMAKE_VERBOSE_MAKEFILE=ON`,
indicating the user wants to have verbose builds (i.e. all executed
commands explicitly echoed), some of the subprojects and runtimes (such
as compiler-rt, libcxx, etc) do not build in verbose mode. For example,
with Ninja:
```
[ 99% 6252/6308] cd /build/runtimes/builtins-bins && /usr/local/bin/cmake --build .
[ 0% 6/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvti2.c.o
[ 0% 7/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o
[ 0% 8/308] Building C object CMakeFiles/clang_rt.builtins-i386.dir/absvsi2.c.o
...
```
This is because `llvm_ExternalProject_Add()` and `add_custom_libcxx()`
use CMake's `ExternalProject_Add()` function to configure such
subproject builds, and do not pass through the `CMAKE_VERBOSE_MAKEFILE`
setting.
Similar to what is done in `clang/CMakeLists.txt`, add
`-DCMAKE_VERBOSE_MAKEFILE=ON` to the `ExternalProject_Add()` invocations
in `llvm_ExternalProject_Add()` and `add_custom_libcxx()`, whenever the
top-level CMake invocation had `CMAKE_VERBOSE_MAKEFILE` turned on.
When building debug version of LLVM with
`LLVM_USE_RELATIVE_PATHS_IN_FILES=On` would cause source paths to be
incorrect, and be prefixed by the build directory. This lead to source
locations like the following: `../build/llvm/...`. Such paths do not
exist, and existing debuggers can't adjust their search location because
of the incorrect prefix. Ultimately, this happened because the relative
path creation goes in the wrong direction, from source-dir to build-dir
instead of from build-dir to source-dir.
This patch swaps the directionality of the relative paths so that they
get a proper prefix from the build directory. Given a build dir at
`/build` and a project directory at `/llvm-project`, we get source
locations like: `../llvm-project/llvm/lib/Transforms/...`, which a
debugger can resolve once pointed to the correct project directory.
This adds dlltool to the list of tools which don't get excluded from
installation when LLVM_INSTALL_TOOLCHAIN_ONLY is set.
The most important effect here is that this tool will now be included in
the official Windows release.
While llvm-lib reuses the dlltool machinary internally and has many of
the same capabilities, it does not expose the functionality controller
by the '-k' flag, which is currently the only way to create import
libraries for i386 with stdcall symbols from a module definition alone.
We avoid changing llvm-lib tool, since it is designed to emulate LIB.EXE
from MSVC toolchain, and as this functionality is not supported there,
we would have had to introduce an LLVM extension flag in order to
support it.
See https://reviews.llvm.org/D36548 for reference on rationale for
dlltool '-k' flag.
This file is a list of files and their required include dirs, used by
the TableGen LSP server
(https://mlir.llvm.org/docs/Tools/MLIRLSP/#tablegen-lsp-language-server--tblgen-lsp-server).
Initialy this only included MLIR TableGen files, so I've expanded that
by moving it into llvm so all projects that use the llvm `tablegen`
function will be added to the file.
You could already do some things in llvm TableGen files without this,
but were limited with files that don't include their dependencies using
`include`, only with command line arguments.
Once those are in the yml file, the language server sees all that and go
to definition etc. all works.
With LTO, gcc's IPA passes might drop the foo() function and then the test
will pass even on platforms where __builtin_thread_pointer is unavailable.
On PPC64, we get this as a result:
```
llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:361:61: error: ‘__builtin_thread_pointer’ is not supported on this targ
```
Just mark the function in the CMake configure test with the 'used' attribute to
avoid it being optimised out. The test then behaves correctly with -flto.
Tested with e.g. 'powerpc64le-linux-gnu-gcc -O2 -flto a.c'.
Reported-by: matoro
Reviewed-by: maskray
Closes: https://github.com/llvm/llvm-project/pull/70968
Signed-off-by: Sam James <sam@gentoo.org>
When the user specifies `LIBCXX_HARDENING_MODE` on the command line in a
bootstrapping build, it should override the setting implied by
`LLVM_ENABLE_ASSERTIONS`.
This PR adds options to let CMake calculate the ninja job pools
depending on free memory and available cores.
You can provide memory requirements for each compile and link job which
is checked against CMake AVAILABLE_PHYSICAL_MEMORY and
NUMBER_OF_LOGICAL_CORES. [This information are available since CMake
3.0](https://cmake.org/cmake/help/v3.0/command/cmake_host_system_information.html).
This is very helpful in CI environments with multiple jobs per
environment or a VM with multiple users.
Its different to LLVM_PARALLEL_LINK_JOBS / LLVM_PARALLEL_COMPILE_JOBS
(or ninja -j 1) because it tries to use the resources more efficient
without being terminated. Only downside currently is that compile and
link jobs can run at the same time so there is an offset for link job
memory suggested which is added to the documentation.
The definitions aren't added as cache because if I understand it
correctly this would break it because values could be outdated.
If a CMake project doesn't enable the C language, then the CMake FFI and
Terminfo find modules will fail their checks for compilation and
linking.
This commit allows projects to enable only C++ by first checking if a C
compiler is set before testing C source compilation; if not, it checks
whether C++ compilation succeeds.
Fixes#53950
`CMAKE_{C/CXX}_FLAGS` affects all targets in LLVM. This can
be undesirable in situations, like the case of enabling thinLTO,
where `-flto` is added to every source file. In reality, we only
care about optimizing a select few of binaries, such as clang or lld,
that dominate the compilation pipeline. Auxiliary binaries in a
distribution and not on the critical path can be kept non-optimized.
This PR adds support of per-target linker flags, which can solve the
thinLTO problem by negating the effects of LTO via targeted linker
flags on the targets. The example of negating thinLTO
above can be done by doing the following:
```
set(LLVM_llvm-dwarfdump_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to llvm-dwarfdump")
set(LLVM_lldb_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to lldb")
```
There's other applications where this could be used (e.g. avoid
optimizing host tools for build speed improvement etc.).
I've generalized this so that users can apply their desired flags to
targets that are generated by `llvm_add_library` or
`add_llvm_executable`.
Internally, our toolchain builds were on average 1.4x faster when
selectively choosing the binaries that we want optimized.
...behind an experimental CMAKE option that's off by default.
This patch adds a new ilist-iterator-like class that can carry two extra bits
as well as the usual node pointer. This is part of the project to remove
debug-intrinsics from LLVM: see the rationale here [0], they're needed to
signal whether a "position" in a BasicBlock includes any debug-info before or
after the iterator.
This entirely duplicates ilist_iterator, attempting re-use showed it to be a
false economy. It's enable-able through the existing ilist_node options
interface, hence a few sites where the instruction-list type needs to be
updated. The actual main feature, the extra bits in the class, aren't part of
the class unless the cmake flag is given: this is because there's a
compile-time cost associated with it, and I'd like to get everything in-tree
but off-by-default so that we can do proper comparisons.
Nothing actually makes use of this yet, but will do soon, see the Phab patch
stack.
[0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939
Differential Revision: https://reviews.llvm.org/D153777
Currently, If the C or C++ compiler supports the `-gsplit-dwarf` option it is added to _all_ compilers.
If a project decides to use another language, such as Swift, this option will be sent to that compiler as well, regardless whether that compiler supports it or not (Swift doesnot).
This patch uses [generator expressions](https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html) to limit the `-gsplit-dwarf` option to only those compilers that support it (C and C++).
It's no longer possible to submit bitcode apps to the Apple App Store.
The tools
used to create xar archived bitcode sections inside MachO files have
been
discontinued. Additionally, the xar APIs have been deprecated since
macOS 12,
so this change removes unnecessary code from objdump and all
dependencies on
libxar.
This fixes rdar://116600767
This is one of the most common issues new users face, especially as so
many reccomended CMake configurations include `-DLLVM_ENABLE_LLD=ON`.
I don't want the error message to get too long but let's at least say
that there are 2 main reasons for the failure. If it's not those then
maybe folks will find the actual problem while trying to discount them.
The new message looks like:
```
CMake Error at cmake/modules/HandleLLVMOptions.cmake:330 (message):
Host compiler does not support '-fuse-ld=not_a_linker'. Please make sure
that 'not_a_linker' is installed and that your host compiler can compile a
simple program when given the option '-fuse-ld=not_a_linker'.
Call Stack (most recent call first):
CMakeLists.txt:910 (include)
```
This patch adds a LLVM_FORCE_VC_REVISION option to force a custom
VC revision to be included instead of trying to fetch one from a
git command. This is helpful in environments where git is not
available or is non-functional but the vc revision is available
through some other means.
This cmake rule is used by external clients, who may or may not have
the LLVM_LIBRARY_OUTPUT_INTDIR variable set.
If it is not set, then we pass `-Wl,-rpath-link,` to the compiler. It
turns out that gcc and clang interpret this differently.
* gcc passes `-rpath-link ""` to the linker, which is what we want.
* clang passes `-rpath-link` to the linker. This is not what we want,
because then the linker gobbles the next command-line argument,
whatever it happens to be, and uses it as the -rpath-link target.
Fix this by passing -rpath-link only if we actually have a path we want.
This has been deprecated in favor of CMake's CMAKE_MSVC_RUNTIME_LIBRARY
in c6bd873403 .
Current release branch still contains it in deprecated status so no
existing end-users will be affected.
Otherwise CMake might throw and error:
CMake Error: try_run() invoked in cross-compiling mode, please set the
following cache variables appropriately:
Z3_RETURNCODE (advanced)
Z3_RETURNCODE__TRYRUN_OUTPUT (advanced)
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
Running lit tests on Windows can fail because its use of
`os.path.realpath` expands substitute drives, which are used to keep
paths short and avoid hitting MAX_PATH limitations.
Changes lit logic to:
Use `os.path.abspath` on Windows, where `MAX_PATH` is a concern that we
can work around using substitute drives, which `os.path.realpath` would
resolve.
Use `os.path.realpath` on Unix, where the current directory always has
symlinks resolved, so it is impossible to preserve symlinks in the
presence of relative paths, and so we must make sure that all code paths
use real paths.
Also updates clang's `FileManager::getCanonicalName` and `ExtractAPI`
code to avoid resolving substitute drives (i.e. resolving to a path
under a different root).
How tested: built with `-DLLVM_ENABLE_PROJECTS=clang` and built `check-all` on both Windows
Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir
Patch by Tristan Labelle <tristan@thebrowser.company>!
GCC 7.3 cannot build 16.x releases.
```
In file included from /tmp/llvm-16/llvm/lib/Transforms/IPO/AttributorAttributes.cpp:14:0:
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: duplicate initialization of ‘llvm::AnalysisGetter::HasLegacyWrapper<Analysis, std::void_t<typename Analysis::Lega
cyWrapper> >’
constexpr bool AnalysisGetter::HasLegacyWrapper<
^~~~~~~~~~~~~~~~~
Analysis, std::void_t<typename Analysis::LegacyWrapper>> = true;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: got 1 template parameters for ‘constexpr const bool llvm::AnalysisGetter::HasLegacyWrapper< <template-parameter-1
-1>, <template-parameter-1-2> >’
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: but 2 required
```
The 17.x and main branches have more failures, e.g.
```
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp: `error: cannot decompose class type ‘std::pair<llvm::Value*, const llvm::SCEV*>’: ...`
```
We probably should just give up 7.1 and say that GCC<=7.3 is unsupported.
There is evidence that GCC 7.4 works.
I have verified that GCC 7.5 is able to build `check-{llvm,clang,clang-tools,lldb,lld,polly,mlir,bolt}`,
but not flang due to at least `flang/Common/enum-class.h` and a `<charconv`> in a unittest.
Link: https://discourse.llvm.org/t/require-gcc-7-5-as-gcc-7-3-cannot-build-llvm/72310
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D156286
This patch is the first part of https://llvm.org/OpenProjects.html#llvm_patch_coverage.
We have first define a new variable LLVM_TEST_COVERAGE which when set, pass --per-test-coverage option to
llvm-lit which will help in setting a unique value to LLVM_PROFILE_FILE for each RUN. So for example
coverage data for test case llvm/test/Analysis/AliasSet/memtransfer.ll will be emitted as
build/test/Analysis/AliasSet/memtransfer0.profraw
Reviewed By: hnrklssn
Differential Revision: https://reviews.llvm.org/D154280
I noticed during the build that GCC would emit a ton of nonnull
warnings.
Example:
```
/usr/local/google/home/fmzakari/code/github.com/llvm/llvm-project/clang/include/clang/AST/ExternalASTSource.h:378:54: warning: ‘this’ pointer is null [-Wnonnull]
378 | Ptr = reinterpret_cast<uint64_t>((Source->*Get)(Ptr >> 1));
| ~~~~~~~~~~~~~~^~~~~~~~~~
```
Reviewed By: MaskRay, rsmith
Differential Revision: https://reviews.llvm.org/D155857
This patch is the first part of https://llvm.org/OpenProjects.html#llvm_patch_coverage.
We have first define a new variable LLVM_TEST_COVERAGE which when set, pass --emit-coverage option to
llvm-lit which will help in setting a unique value to LLVM_PROFILE_FILE for each RUN. So for example
coverage data for test case llvm/test/Analysis/AliasSet/memtransfer.ll will be emitted as
build/test/Analysis/AliasSet/memtransfer.profraw
Reviewed By: hnrklssn
Differential Revision: https://reviews.llvm.org/D154280
Due to arguably a bug in GCC[0], using `__has_builtin` is not sufficient to check whether `__builtin_thread_pointer` can actually be compiled by GCC. This makes it impossible to compile LLVM with `llvm-exegesis` enabled with e.g. GCC 10 as it does have the builtin, but no implementation for architectures such as x86.
This patch works around this issue by making it a cmake configure check whether the builtin can be compiled and used, rather than relying on the broken preprocessor macro.
[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952, demonstration: https://godbolt.org/z/9z5nWM6Ef
Differential Revision: https://reviews.llvm.org/D155828
This was left in place to reduce the risk of breaking anything,
and to keep the diff smaller, in D155233.
Differential Revision: https://reviews.llvm.org/D155431
With the new behaviour, the /MD or similar options aren't added to
e.g. CMAKE_CXX_FLAGS_RELEASE, but are added separately by CMake.
They can be changed by the cmake variable
CMAKE_MSVC_RUNTIME_LIBRARY or with the target property
MSVC_RUNTIME_LIBRARY.
LLVM has had its own custom CMake flags, e.g. LLVM_USE_CRT_RELEASE,
which affects which CRT is used for release mode builds. Deprecate
these and direct users to use CMAKE_MSVC_RUNTIME_LIBRARY directly
instead (and do a best effort attempt at setting CMAKE_MSVC_RUNTIME_LIBRARY
based on the existing LLVM_USE_CRT_ flags). This only handles the
simple cases, it doesn't handle multi-config generators with
different LLVM_USE_CRT_* variables for different configs though,
but that's probably fine - we should move over to the new upstream
CMake mechanism anyway, and push users towards that.
Change code in compiler-rt, that previously tried to override the
CRT choice to /MT, to set CMAKE_MSVC_RUNTIME_LIBRARY instead of
meddling in the old variables.
This resolves the policy issue in
https://github.com/llvm/llvm-project/issues/63286, and should
handle the issues that were observed originally when the
minimum CMake version was bumped, in
https://github.com/llvm/llvm-project/issues/62719 and
https://github.com/llvm/llvm-project/issues/62739.
Differential Revision: https://reviews.llvm.org/D155233
Add an option to specify additional linker flags for unit tests only.
For example, this allows using something like
-DLLVM_UNITTEST_LINK_FLAGS="-Wl,-plugin-opt=O0" if you're doing LTO
builds, or -DLLVM_UNITTEST_LINK_FLAGS="-fno-lto" if you're using
fat LTO objects.
The build system already does this itself if the LLVM_ENABLE_LTO
flag is used, but this does not cover all possible LTO configurations.
Differential Revision: https://reviews.llvm.org/D154212
This reverts commit f55fd19b6b.
As noted on the original thread, other uses of LLVM_LIBRARY_OUTPUT_INTDIR are optional. Will make a separate patch that makes this use optional as well.
It looks like MLIR is using the more modern CMAKE_LIBRARY_OUTPUT_DIRECTORY, but AddLLVM still uses this older LLVM specific alias.
In the specific case I was running into, the empty variable was causing `-Wl,-rpath-link,` on the command line, causing the following argument to be swallowed. This was maddening, because the following argument was the .o file containing `main` and I was getting `main` undefined errors when it was clearly there. This is egregious enough that I chose to guard it.
Differential Revision: https://reviews.llvm.org/D153373
Testing libc++ with CMake 3.27.0-rc1 fails. It seems some of the modules
used in CMake are not included.
The error before this change was
```
CMake Error at <mono-repo>/llvm/cmake/modules/HandleLLVMOptions.cmake:821 (CHECK_C_SOURCE_COMPILES):
Unknown CMake command "CHECK_C_SOURCE_COMPILES".
Call Stack (most recent call first):
CMakeLists.txt:156 (include)
```
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D152619
Currently both ASAN and UBSAN are supported on Windows but only ASAN is enabled in LLVM build system. This patch enables the option to build LLVM with UBSAN on windows.
Tested with clang-cl released in LLVM16.
Submitting on behalf of @dwang.
Reviewed by: andrewng, pgousseau
Differential Revision: https://reviews.llvm.org/D151511
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 75a0502fe0 (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
