| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Hoist handling of Doxygen into the top-level cmake/ directory so it can
be shared between LLVM and RUNTIMES and a default/standalone runtimes
build can support building Doxygen documentation as well.
The openmp subproject currently supports doxygen documentation using an
`LLVM_ENABLE_PROJECTS=openmp` build, but not with
`LLVM_ENABLE_RUNTIMES=openmp` because of this missing boilerplate code
in the runtimes build. This is a step towards removing the
`LLVM_ENABLE_PROJECTS=openmp` build mode which was deprecated (#124014)
and already scheduled to be removed in LLVM 21 (#136314). Eventual
removal is planned with #176950.
Hoisting CMake code for shared use with runtimes has been done before in
e.g. #84641, 7017e6c9cfd2de3122ce9528f338a97d61e96373,
44e3365775101fec3fd355eda339282258d74415,
7017e6c9cfd2de3122ce9528f338a97d61e96373
---------
Co-authored-by: Petr Hosek <phosek@google.com>
|
|
|
|
doing `find_package(gRPC)` (#173115)
`PACKAGE_VERSION` is important since it sets the `LLVM_VERSION_STRING`
string.
|
|
(#169638)"
This reverts commit 7675fc79c802cf7f6a95660f6ee59bf6cb62102f.
Requested in PR:
https://github.com/llvm/llvm-project/pull/169638#issuecomment-3634227707
|
|
Reapplication of #137828, changes:
* Workaround CMAKE_Fortran_PREPROCESS_SOURCE issue for CMake < 2.24: The
issue is that `try_compile` does not forward manually-defined compiler
flang variables to the test build environment; instead of just a
negative test result, it aborts the configuration step itself. To be
fair, manually defining these variables is deprecated since at least
CMake 3.6.
* Missing flang cmd line flags for CMake < 3.28 `-target=`, `-O2`, `-O3`
* It is now possible to set FLANG_RT_ENABLED_STATIC=OFF and
FLANG_RT_ENABLE_SHARED=OFF at the same and is the default for amdgpu and
nvptx targets. In this mode, only the .mod files are compiled --
necessary for module files in
lib/clang/22/finclude/flang/(nvptx64-nvidia-cuda|amdgpu-amd-amdhsa)/*.mod
to be available.
* For compiling omp_lib.mod for nvptx and amdgpu, the module build
functionality must be hoisted out if openmp's runtime/ directory which
is only included for host targets. This PR now requires #169909.
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Constants such as [`c_long_double` also have different
values](https://github.com/llvm/llvm-project/blob/d748c81218bee39dafb9cc0c00ed7831a3ed44c3/flang-rt/lib/runtime/iso_c_binding.f90#L77-L81).
Most other modules have `#ifdef`-enclosed code as well. For instance
this caused offload targets nvptx64-nvidia-cuda/amdgpu-amd-amdhsa to use
the modules files compiled for the host which may contrain uses of the
types REAL(10) or REAL(16) not available for nvptx/amdgpu.
#146876
#128015
#129742
#158790
3. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
4. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted (PR
#169525).
If using Flang for cross-compilation or target-offloading, flang-rt must
now be compiled for each target not only for the library, but also to
get the target-specific module files. For instance in a bootstrapping
runtime build, this can be done by adding:
`-DLLVM_RUNTIME_TARGETS=default;nvptx64-nvidia-cuda;amdgpu-amd-amdhsa`.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Another subdirectory `flang` avoids accidental inclusion of
gfortran-modules which due to compression would result in
user-unfriendly errors. Now the driver adds `-fintrinsic-module-path`
for that location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
|
|
Reverts llvm/llvm-project#137828
Buildbot error in
https://lab.llvm.org/staging/#/builders/105/builds/37275
|
|
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Most other modules have `#ifdef`-enclosed code as well.
2. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
3. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Now the driver adds `-fintrinsic-module-path` for that
location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
|
|
Update the logic to find gRPC to always favor CMake `find_package`
implementation including for builds on macOS that uses homebrew, where
gRPCConfig.cmake is also installed to provide an accurate target
dependencies to link against.
This fixes the problem that newer gRPC version has broken up the
libraries into smaller pieces and the hard coded list of libraries in
the implementation can no longer work.
Fixes: https://github.com/llvm/llvm-project/issues/59844
|
|
On AIX we prefer to create shared libraries as shared library archives
(i.e. we archive the shared object in a big AR archive) as this is the
standard format on the platform.
There is now a CMake policy that allows us to do this by default, so
opt-in to that behaviour.
---------
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
|
|
When single-threaded mode is selected, all instances of the keyword
`LIBC_THREAD_LOCAL` are stubbed out, similar to how it currently works
on the GPU. This allows baremetal builds to avoid using thread_local.
However, libcxx uses shared headers, so we need to be careful there.
Thankfully, there is already an option to disable multithreading in
libcxx, so a flag is added such that single-threaded mode is propagated
down to libc.
|
|
|
|
Currently an absolute CLANG_RESOURCE_DIR is treated as being relative
to bin. Fix that by using cmake_path(APPEND) to append the path to bin.
The prepending of PREFIX is left as-is because callers passing PREFIX
are usually forming a path within the build directory and would not
want build products to be written to an absolute resource directory
that is likely to be an installation prefix. One exception is the caller
in lldb/cmake/modules/LLDBStandalone.cmake; for now it is not possible
to build LLDB with an absolute resource directory until the users are
disambiguated.
Reviewers: petrhosek
Reviewed By: petrhosek
Pull Request: https://github.com/llvm/llvm-project/pull/145996
|
|
This reverts commit fa65a228f4b46346e69e9b95805a8bcfa8483a60.
This relands commit ab405fb6e9ff9202ca722f632b945d4b84c653f5.
There was an issue where CMake versions <3.23.0 would not properly parse
dep files, causing the build to file. This patch fixes that by just
making CMake versions <3.23.0 use the fallback behavior.
|
|
This reverts commit ab405fb6e9ff9202ca722f632b945d4b84c653f5.
This caused quite a few buildbot failures that need further
investigation.
|
|
CMP0116 was originally set to old to get rid of warnings. However, this
behavior is now set to new by default with the minimum CMake version
that LLVM requires so does not produce any warnings, and setting it
explicitly to old does produce a warning in newer CMake versions. Due to
these reasons, remove this check for now.
Splitting off from removing the CMP0114 check just in case something
breaks.
Partially fixes #83727.
|
|
When determining the install prefix in LLVMConfig.cmake etc resolve
symlinks in CMAKE_CURRENT_LIST_FILE first. The motivation for this is to
support symlinks like `/usr/lib64/cmake/llvm` to
`/usr/lib64/llvm19/lib/cmake/llvm`. This only works correctly if the
paths are relative to the resolved symlink.
It's worth noting that this *mostly* already works out of the box,
because cmake automatically does the symlink resolution when the library
is found via CMAKE_PREFIX_PATH. It just doesn't happen when it's found
via the default prefix path.
|
|
(#131586)
Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.
|
|
Also clear the release notes.
|
|
LLD has a bug regarding ordering of static link libraries in the ELF backend, which has been reported as #116669.
CMake 3.31.0 started properly deduplicating static libraries for LLD causing the following linking failure for `libclang-cpp.so` with `-DLLVM_LINK_LLVM_DYLIB=ON`:
```
ld.lld: error: undefined symbol: llvm::omp::getOpenMPClauseName(llvm::omp::Clause)
>>> referenced by OpenMPKinds.cpp
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/OpenMPKinds.cpp.o:(clang::getOpenMPSimpleClauseTypeName(llvm::omp::Clause, unsigned int))
>>> referenced by SemaOpenMP.cpp
>>> tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced by SemaOpenMP.cpp
>>> tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced 166 more times
[tons more]
```
CMake 3.31 also introduced CMP0179, which builds on CMP0156 and makes the deduplication consistent across platforms.
By coincidence this works around the above LLD deficiency and is the fix that CMake 3.31.1 will implement.
However, the fix is to ignore CMP0156 unless CMP0179 is also enabled, i.e. no more deduplication.
So enable CMP0179 to keep the benefits of deduplication from CMP0156 on LLD and fix the build for CMake 3.31.0.
See: #116669
See: https://gitlab.kitware.com/cmake/cmake/-/issues/26447
Fixes: cb90d5b
|
|
Some linkers do not require that libraries are repeated on the command
line. The Apple linker emits warnings when duplicate libraries are
specified, resulting in a wall of warnings.
CMP0156 deduplicates libraries on the command line when the linker
doesn't require them.
This patch enables CMP0156 to quiet the warnings when using a version of
CMake that recognizes it (CMake 3.29 and newer).
|
|
standalone build (#112741)
The runtimes used to support a build mode called the "Standalone build",
which isn't supported anymore (and hasn't been for a few years).
However, various places in the code still contained stuff whose only
purpose was to support that build mode, and some outdated documentation.
This patch cleans that up (although I probably missed some).
- Remove HandleOutOfTreeLLVM.cmake which isn't referenced anymore
- Remove the LLVM_PATH CMake variable which isn't used anymore
- Update some outdated documentation referencing standalone builds
|
|
This makes the message stand out a bit more, which can be helpful to
debug situations where compiler-rt is missing but shouldn't.
|
|
CMP0114 was originally set to old to get rid of warnings. However, this
behavior is now set to new by default with the minimum CMake version
that LLVM requires so does not produce any warnings, and setting it
explicitly to old does produce a warning in newer CMake versions. Due to
these reasons, remove this check for now.
Splitting off from removing the CMP0116 check just in case something
breaks.
Partially fixes #83727.
|
|
Closes #38383.
This enables parallel custom build commands, which improve compilation
time on Windows with Visual Studio.
|
|
Not every toolchain provides and want to use libatomic which is a part
of GCC, some toolchains may opt into using compiler-rt atomic library.
|
|
Broken out from #93429
Somewhat closing the loop opened by 7017e6c9cfd2de.
Co-authored-by: Ryan Prichard <rprichard@google.com>
|
|
LLVM 19 release is starting.
|
|
- Enable CMP0144 policy if available, this will make the find_package()
more robust.
Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
|
|
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the tests. This allows a clang built on a machine with a new linker
to run compiler-rt tests on a machine with an old linker.
rdar://125198603
|
|
|
|
|
|
This allows sharing the LLVM version number in libc++.
|
|
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
|
|
A project that bundles the llvm source code may have their own
PACKAGE_VERSION variable, so only use this to compute the
CLANG_RESOURCE_DIR if CLANG_VERSION_MAJOR is undefined.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D152608
|
|
re-commit of 39aa0f5c434b463520ac39a8dbe933ee8c4c5ea7 with missing file:
cmake/Modules/GetClangResourceDir.cmake.
|
|
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
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.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes #62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
|
|
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.
|
|
The build uses other mechanism to select the runtime.
Fixes #62719
Differential revision: https://reviews.llvm.org/D150688
|
|
This is a follow-up to D147153 and addresses CMake warnings about not
finding LibEdit find module when another project uses LLVM as a
dependency.
Fixes https://github.com/llvm/llvm-project/issues/62300
Reviewed By: Dinistro
Differential Revision: https://reviews.llvm.org/D148993
|
|
llvm_check_compiler_linker_flag"
This reverts commit 55e65ad876e3ac0b1cb0410a5cce3554c009af65.
|
|
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
|
|
llvm_check_compiler_linker_flag"
libc++ clang-cl tests failed after that commit
Look at https://buildkite.com/llvm-project/libcxx-ci/builds/20490
Reviewed By: #libc
Differential Revision: https://reviews.llvm.org/D145858
This reverts commit b00aaab730ae8bd7f8a44e1808e668e20c2c9282.
|
|
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
|
|
llvm_check_compiler_linker_flag"
This reverts commit efae3174f09560353fb0f3d528bcbffe060d5438 since
it broke the standalone Flang build.
|
|
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
|
|
dependencies too"
This reverts commit 9f3081dc6fe8447e85741865846840bc491866e5.
Broke clangd buildbots in
https://lab.llvm.org/buildbot/#/builders/131/builds/38935.
|
|
Fixes: https://github.com/llvm/llvm-project/issues/59844
Differential Revision: https://reviews.llvm.org/D141047
|
|
Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:
CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
Unknown CMake command "cmake_push_check_state".
Call Stack (most recent call first):
cmake/modules/LLDBConfig.cmake:52 (find_package)
cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
CMakeLists.txt:28 (include)
Gentoo Bug: https://bugs.gentoo.org/880065
Differential Revision: https://reviews.llvm.org/D137555
|
|
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
|
