This reverts commit 42eb7db188. This
reland 3fbb037d03 (#209922).
Under CMake 4+, calling add_library(... SHARED IMPORTED) on a target
platform that lacks dynamic linking support triggers a fatal error. This
becomes an issue when building LLVM and runtimes for baremetal targets
like armv6m-none-eabi. This patch adds the option
"LLVM_OMIT_EXPORTS_FROM_CONFIG" in LLVM. When used in sub builds like
LLVM runtimes, it makes CMake to skip including the LLVM and Clang
exports. This mitigates the CMake 4 errors on baremetal runtimes.
42eb7db188 originally
apply this flag on all runtimes build and causing issues on runtimes
like intel-sycl-gpu, amdgpu-offload-ubuntu-22-cmake-build-only.
This PR only set this flag when the target platform lacks shared library
support.
Under CMake 4+, calling add_library(... SHARED IMPORTED) on a
target platform that lacks dynamic linking support triggers a fatal
error. This becomes an issue when building LLVM and runtimes for
baremetal targets like armv6m-none-eabi. This patch
adds the option "LLVM_OMIT_EXPORTS_FROM_CONFIG" in LLVM.
When used in sub builds like LLVM runtimes, it makes CMake to skip
including the LLVM and Clang exports. This mitigates the CMake 4
errors on baremetal runtimes.
Two fixes when using CMake < 3.28 after #209482:
* In addition to `flang`, also recognize `fakeflang` to determine
whether any workaround for CMake not completely supporting Flang is
needed. `fakeflang` is used as a shim in #209482.
* For CMake < 3.24, CMake does not reognize Flang at all and tries other
methods to detect to the compiler, including the file `CMakeTestGNU.c`.
Make `fakeflang` recognize it as a probe attempt.
This should fix the
[openmp-offload-amdgpu-clang-flang](https://lab.llvm.org/buildbot/#/builders/67)
buildbot. The buildbot is currently upgrade to a newer CMake version,
and the minimum required version of CMake will become 3.31 soon.
The change broke the runtimes build for Android; see discussion on the
PR. There are fixes in progress, but let's revert to unbreak the tree
until all those are ready to land.
This reverts commit 00b2f81418 and the
follow-up commit 1008b485e4.
Use CMake INTERFACE libraries to express dependencies and common build
options.
Using INTERFACE libraries was proposed here:
https://github.com/llvm/llvm-project/pull/171610#discussion_r3122187957
Since such libraries can also propagate build options use this instead
of `target_compile_options`. Unfortunately this does not mean we can get
rid of `flang_module_target` because it also needs to set the module
output directory.
---------
Co-authored-by: Tarun Prabhu <tarunprabhu@gmail.com>
Two build failures reported after #204260
* Unix Makefiles generator stops working: The cause is that the rules
for building each OBJECT library lands in its own Makefile, e.g.
`flang_rt.mod.fortran.builtins.dir/build.make` and
`libomp-mod.dir/build.make`. Trying to inject dependencies directly for
build rules in the other file does not work.
* `__ppc_types.f90` not tracked: Forgotten in #204260 due to being only
conditionally enabled for PowerPC targets.
The solution for both is to just remove the workaround for CMake not
recognizing modules uses declared using `intrinsic` which caused these
problems. This PR promotes the `use` constructs in the module sources to
normal dependencies that are not ignored by CMake.
The `intrinsic` modifier changes the search path to only look for such a
module in `-fintrinsic-modules-path`. The difference is only
theoretical:
1. When compiling the intrinsic modules, there are no other search paths
than for the intrinsics anyway
2. Users should strongly avoid naming their modules the same as an
intrinsic module
3. Most of our intrinsic sources don't even use the `intrinsic` modifier
in the first place (e.g.
1c9412432f/flang-rt/lib/runtime/__cuda_builtins.f90 (L13)).
That is, if there was a problem with lookup ambiguity, these would have
already been a problem for those.
4. The checksum of used modules is only added into the .mod file (the
only reason why modules would need to be transitively rebuilt) when a
`use` statement appears. Many intrinsic modules don't explicitly use the
modules that are added implicitly by the compiler, such as
`__fortran_builtins`, and hence do not even need to be rebuilt.
I started this PR with a tested-working fix
([71c5e7f0ffcf2ebd58812d2e2812b22663be1631](https://github.com/llvm/llvm-project/pull/205634/changes/BASE..71c5e7f0ffcf2ebd58812d2e2812b22663be1631))
to the workaround code. But given the points above, there seems to be no
benefit of keeping the workaround code handling CMake version < 4.5
around just for some intrinsic modules to keep the `intrinsic` modifier
with no practical effect. A non-workaround path using CMake's
`Fortran_BUILDING_IN(S)TRINSIC_MODULES` setting had to be added in any
case for Unix Makefile generators (reported issue 1.) because injecting
dependencies is not possible with Unix Makefiles as stated, but
`Fortran_BUILDING_IN(S)TRINSIC_MODULES` also does not work with the
Ninja generator. Avoiding `use, intrinsic` keeps just one configuration
path.
I tested that modules are properly updated with Ninja and Unix
Makefiles:
* Build from scratch
* Modifying `__fortran_builtins.f90` rebuilds its dependent modules
* Modifying `iso_c_binding.f90` rebuilds its dependent modules
(omp_lib.mod)
Compute the cmake system name from the target triple, rather
than passing through the host's. This is primarily to stop
forwarding OSX specific cmake variables.
This fixes build failures when trying to build gpu libc on mac
hosts. Previously it would fail on several issues, starting with
an unused argument -mmacos-version-min error, followed by other
errors caused by passing -isysroot.
Secondarily, restrict the cmake imported targets when cross compiling.
Without this, the amdgpu build prints many cmake warnings about the
target not supporting shared libraries.
Claude did most of the actual work, though it required quite a few
rounds of prodding to get it into the right place. In particular it
took care of handling all of the cmake platform recognized names from
the triple.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Add a mock driver to pass CMake's compiler introspection for
CMake_Fortran_COMPILER. It's purpose is to not having to build the full
flang compiler for the runtimes-configure phase in
bootstrapping-runtimes builds, but only when the Fortran compiler is
actually needed (e.g. flang-rt-mod, libomp-mod).
To detect LLVMFlang, CMake executes
```
${CMAKE_Fortran_COMPILER} -v -c -target=... CMakeFortranCompilerId.F
```
and expects a new file to appear in the working directory. This would
usually be an object file (e.g. ELF), but it doesn't matter for CMake as
it parses it for the preprocessor result of CMakeFortranCompilerId.F
which would appear as string literals in the binary file (CMake cannot
execute the file because it might be cross-compiling). Just passing it
through the preprocessor yields the same result. The most relevant
preprocessor definition is __flang__ which leads to
CMAKE_Fortran_COMPILER_ID="LLVMFlang".
This is more robust than #198205:
1. It does not rely on `CMake_Fortran_COMPILER_FORCED` which the CMake
manual documents as [Do not
use](https://cmake.org/cmake/help/latest/module/CMakeForceCompiler.html),
nor the undocumented `CMAKE_Fortran_COMPILER_ID_RUN`.
2. Incremental builds are more robust, there should be no risk of the
make program (ninja/make) mistakenly interpreting the empty/mock
executable as the up-to-date build artifact. Creating the shim/empty
flang executable is done in the outer bootstrapping built (rather than
in the inner runtimes build); having control over both rules that create
bin/flang allows this.
Also fixes the problem that check-flang-rt/check-openmp [do not trigger
(re-)building
flang](https://github.com/llvm/llvm-project/pull/198205#pullrequestreview-4412291879).
I think it should fix intermittend failures of the premerge-CI such as
https://github.com/llvm/llvm-project/actions/runs/27389890881/job/80947804137?pr=203400.
Design considerations:
* This relies on the way how CMake currently introspects the compiler.
However, I expect it to stay "look into the produced files" in the
foreseable future and will also not rely on runtime string concatenation
because debug builds may not ptimize them into a single string constant.
That is, there are reasons CMake can only rely on the preprocessor. The
Fortran standard does not mandate a preprocessor, yet CMake relies on
it.
* There is one situation where incremental builds to not completely
work: deleting bin/flang manually and then building runtimes-configure
will not recreate either bin/flang. No impact if runtimes-configure was
actually run before because in that case CMake has already cached the
CMAKE_Fortran_COMPILER inspection result.
* ninja does not allow two rules to create the same file (one to create
bin/flang only if it is missing and another that replaces it with the
full flang), one of the build artifacts must be undeclared. That could
be the full flang would only be created explicitly with a separate
`flang-eager` target (flang itself have the output
`bin/flang-<version>`, `bin/flang` is the symlink to it), but that would
require more intrusive changes.
The previous attempt at this (b7da956501)
still broke standalone builds. Now I have locally tested standalone
flang, runtimes (with openmp), lldb, combined builds, and the utils
script. Hopefully that covers everything this time, and gets everything
into a more consistent state (always using the HandleDoxygen script in
the same way, included exactly once as required by the cmake design).
The PR #198205 sets CMAKE_Fortran_SIMULATE_ID to "GNU", since Flang has
no alternative driver such as an equivalent to clang-cl. But it breaks
the Windows build with
```
LINK : warning LNK4044: unrecognized option '/lpsapi'; ignored
LINK : warning LNK4044: unrecognized option '/lshell32'; ignored
LINK : warning LNK4044: unrecognized option '/lole32'; ignored
LINK : warning LNK4044: unrecognized option '/luuid'; ignored
LINK : warning LNK4044: unrecognized option '/ladvapi32'; ignored
LINK : warning LNK4044: unrecognized option '/lws2_32'; ignored
LINK : warning LNK4044: unrecognized option '/lntdll'; ignored
LINK : warning LNK4044: unrecognized option '/ldelayimp'; ignored
```
The reason is interesting. With CMAKE_Fortran_SIMULATE_ID=GNU, CMake
will include the Windows-GNU.cmake
platform file. That file overwrites CMAKE_LINK_LIBRARY_FLAG with
`-l` which is GNU convention for the linker flag. But since
CMAKE_LINK_LIBRARY_FLAG is global (in contrast to a per-language
setting), it changes the flags for link.exe/lld-link.exe even when
compiling C/C++ applications. CMake internally converts `-l` to `/l` for
convenience.
Set CMAKE_Fortran_SIMULATE_ID to the same as CMAKE_CXX_SIMULATE_ID as
originally proposed in #198205. While flang.exe is a GNU-style driver,
setting it to "MSVC" still works, probably because there is no
alternative set of flags for Flang. Also define some additional
variables that CMake stores in `CMakeFortranCompiler.cmake` in the build
directory when CMake is allowed to introspect the Flang driver itself.
Should fix the buildbots
flang-arm64-windows-msvc-testsuite,
flang-arm64-windows-msvc,
flang-x86_64-windows
Summary:
When LLVM_BINARY_DIR was not set this should default to a root location
and configuration would fail by trying to write to some random system
location with insufficient perms.
Fixes the failure introduced in
https://github.com/llvm/llvm-project/commit/b4f5ae234c6d
Summary:
This PR cuts `flang` out of the core runtimes configure dependency. We
will need the runtimes infrastructure to handle `flang` module
generation, but this dependency poisons the entire dependency stack.
`flang` and `mlir` are by far the heavily parts of the LLVM stack and
for distribution we want to only build it when absolutely necessary,
which as of now is only to install flang module files.
The approach here is to simply remove the `flang` target from the core
dependency tree, but intead configure it for the top-level `module`
targets which are part of `all`. To make this work we need to pass
COMPILER_WORKS and set up a dummy location so that configuration passes.
it's a little backdoor, but this is an extremely important quality of
life improvement for LLVM distribution support.
Reapplication of #137828 and #169638
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).
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.
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.
Currently the dependencies between builtin modules and `omp_lib.mod`
seem to be incorrect:
https://github.com/llvm/llvm-project/pull/174474#issuecomment-3880189581
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 (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).
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=...`.
libclc has configure warning on Windows:
clang: error: no such file or directory:
'/clang:--target=amdgcn-amd-amdhsa-llvm' clang: error: no such file or
directory: '/clang:-print-target-triple'
CMake Warning at CMakeLists.txt:239 (message):
Failed to execute `llvm-project/build/bin/clang.exe
/clang:--target=amdgcn-amd-amdhsa-llvm /clang:-print-target-triple` to
normalize target triple.
Switch to check CMAKE_C_COMPILER_FRONTEND_VARIANT because
- CMAKE_C_SIMULATE_ID=MSVC: true for both clang and clang-cl.
- CMAKE_C_COMPILER_FRONTEND_VARIANT=MSVC: true for clang-cl; false for clang.
As seen in https://github.com/android/ndk/issues/2188, NDK will raise
minimum supported version to API 23 (Android 6.0) in r31. We need to
bump the API level for the x86 emulator image so we can use it for the
CI. It required generating a new ABI list for API 23 and removing the
old API 21 and making some changes to adb_run.py to filter out warnings
and get permissions for the adb run folder.
Only enable Fortran support when the user (or the bootstrapping build)
passes `-DCMAKE_Fortran_COMPILER=...`.
`enable_language(...)` other than C/CXX reveals problems with the
current build system. LLVM likes to add
`-Wl,--color-diagnostics`
to `CMAKE_EXE_LINKER_FLAGS` whenever possible. The problem is that
`CMAKE_EXE_LINKER_FLAGS` is added to the linker line regardless of which
language is used, but `HandleLLVMOptions.cmake` probes only
`CMAKE_CXX_COMPILER`. Other languages' compilers such as
`CMAKE_CUDA_COMPILER` (`nvcc`) or `CMAKE_Fortran_COMPILER` (`gfortran`)
may not accept the flag. CMake then fails when those compilers are "not
able to compile a simple test program." because it does not accept the
`--color-diagnostics` flag.
`CMAKE_EXE_LINKER_FLAGS` does not support generator expression such that
`$<$<COMPILE_LANGUAGE:C,CXX>:-Wl,--color-diagnostics>` does not work
either.
We disable automatic detection of a Fortran compiler out of precaution
if other such problems are found. The bootstrapping build will pass
just-built Clang and Flang together which are compatible to each other.
In runtimes default/standalone builds, users will have to pass the
compiler explicitly if they want Fortran modules.
The CMake `install(DIRECTORY ..)` command requires the source directory
to exist or it withh throw an error:
```
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot find
"C:/Users/meinersbur/src/llvm/main/release/lib/clang/23/finclude/flang/x86_64-pc-windows-msvc":
No error.
```
The install command was added by #171610 directory is currently empty by
design to be filled with the upcoming #171515.
Should fix the flang-arm64-windows-msvc-testsuite buildbot. For some
reason the nested `ninja install` call inside `runtimes/runtimes-bins`
fails but the outer `ninja install` silently just does not install the
nested files.
Unlike everything else in CMake, cmake_path does not assume a default
value for undefined variables, but instead throws an error:
```
CMake Error at cmake/config-Fortran.cmake:77 (cmake_path):
cmake_path undefined variable for input path.
Call Stack (most recent call first):
CMakeLists.txt:284 (include)
```
Protect the use of cmake_path to not trigger this error when
CMAKE_Fortran_COMPILER is undefined.
Fixes the flang-aarch64-out-of-tree buildbot after #171610.
Common CMake code to be used by flang-rt and openmp to emit Flang module
files. Most of the code is not yet used within this PR.
Extracted out of #171515 for review by @petrhosek.
Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
Summary:
This PR primarily changes using `LLVM_RUNTIMES_TARGET` to
`LLVM_DEFAULT_TARGET_TRIPLE`. The reason is that the default target
triple is the true cross-compiling architecture we are using, while the
runtimes_target can contain multilib strings like `+debug` or similar.
Additionally add the proper path handling to the OpenMP / Offload
libraries.
Allow runtime source directories to live outside the top-level tree by
honoring LLVM_EXTERNAL_*_SOURCE_DIR and propagating the values via
RUNTIMES_CMAKE_ARGS.
Summary:
This PR provides the minimal support for Fortran I/O coming from a GPU
in OpenMP offloading. We use the same support the `libc` uses for its
printing through the RPC server. The helper functions `rpc::dispatch`
and `rpc::invoke` help make this mostly automatic.
Becaus Fortran I/O is not reentrant, the vast majority of complexity
comes from needing to stitch together calls from the GPU until they can
be executed all at once. This is needed not only because of the
limitations of recursive I/O, but without this the output would all be
interleaved because of the GPU's lock-step execution.
As such, the return values from the intermediate functions are
meaningless, all returning true. The final value is correct however. For
cookies we create a context pointer on the server to chain these
together.
Works on both my AMD and NVIDIA GPUs.
```fortran
program hello_gpu
implicit none
!$omp target teams num_teams(1)
!$omp parallel num_threads(2)
! Print strings
print *, "Hello from GPU"
!$omp end parallel
!$omp end target teams
end program hello_gpu
```
```console
> flang hello.f90 -O2 -fopenmp --offload-arch=gfx1030
> ./a.out
Hello from GPU
Hello from GPU
> flang hello.f90 -O2 -fopenmp --offload-arch=sm_89
> ./a.out
Hello from GPU
Hello from GPU
```
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, 7017e6c9cf,
44e3365775,
7017e6c9cf
---------
Co-authored-by: Petr Hosek <phosek@google.com>
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](d748c81218/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=...`.
This replaces detection of picolibc in libc++ (by checking for and
including picolibc.h) with using RUNTIMES_USE_LIBC build time option
intriduced in https://github.com/llvm/llvm-project/pull/134893
RUNTIMES_USE_LIBC is extended to accept picolibc and newlib.
Detection of picolibc via the header is kept as a deprecated feature to
avoid breaking builds.
libc++ is updated to use dedicated LIBCXX_LIBC_NEWLIB macro to check for
newlib specific conditions instead of less informative _NEWLIB_VERSION
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
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=...`.
Post-commit fix of #164794 reported at
https://github.com/llvm/llvm-project/pull/164794#issuecomment-3536253493
`LLVM_LIBRARY_OUTPUT_INTDIR` and `LLVM_RUNTIME_OUTPUT_INTDIR` is used by
`AddLLVM.cmake` as output directories. Unless we are in a
bootstrapping-build, It must not point to directories found by
`find_package(LLVM)` which may be read-only directories. MLIR for
instance sets thesese variables to its own build output
directory, so should the runtimes.
The LLVM-customized GTest has a dependency on LLVM to support
`llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes
use the LLVMSupport from the bootstrapping LLVM build. The problem is
that the boostrapping compiler and the runtimes target can diverge in
their ABI, even in the runtimes default build. For instance, Clang is
built using gcc which uses libstdc++, but the runtimes is built by Clang
which can be configured to use libcxx by default. Altough it does not
use gcc, this issue has caused
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to
break, and is still (again?) broken.
This patch makes the runtimes' GTest independent from LLVMSupport so we
do not link any runtimes component with LLVM components.
Runtime projects that use GTest unittests:
* flang-rt
* libc
* compiler-rt: Adds `gtest-all.cpp` with
[GTEST_NO_LLVM_SUPPORT=1](f801b6f67e/compiler-rt/CMakeLists.txt (L723))
to each unittest without using `llvm_gtest`. Not touched by this PR.
* openmp: Handled by #159416. Not touched for now by this PR to avoid
conflict.
The current state of this PR tries to reuse
https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt
as much as possible, altough personally I would prefer to make it use
"modern CMake" style. third-party/unittest/CMakeLists.txt will detect
whether it is used in runtimes build and adjaust accordingly. It creates
a different target for LLVM (`llvm_gtest`, NFCI) and another one for the
runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest`
for both since `llvm_gtest` is imported using `find_package(LLVM)` if
configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to
select between the two. `default_gtest` could also be used for openmp
which also supports standalone and
[LLVM_ENABLE_PROJECTS](https://github.com/llvm/llvm-project/pull/152189)
build mode.
Based on the discussion in
https://discourse.llvm.org/t/rfc-execute-only-code-support-for-runtime-libraries-on-aarch64/86180
a single, global configuration option should be used to enable
execute-only code generation for the runtime libraries. The new option
`RUNTIMES_EXECUTE_ONLY_CODE` adds the `-mexecute-only` flag to
`CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS`, which simplifies the
library-level configuration needed for the runtime libraries.
Project-specific changes are still needed to handle assembly sources,
e.g. in compiler-rt and libunwind.
Summary:
The changes in
43bd7e3bb9
altered how we handled including headers, this included the system on
the GPU target which poisoned the include path that was curated to not
include any system headers. Change this to only apply is the target OS
is Linux.
When setting RUNTIMES_USE_LIBC=libc we pass -nostdlibinc if the compiler
supports it. This causes compilation failures when trying to build
libc++ as libc will try and reference kernel headers in its own headers
that it now cannot find. Explicitly reference the kernel headers so the
compiler can find them.
Reviewers: vonosmas, petrhosek, #reviewers-libcxx, michaelrj-google
Reviewed By: michaelrj-google
Pull Request: https://github.com/llvm/llvm-project/pull/165114
Ensure that LLVM_LIBRARY_DIR uses LLVM_LIBDIR_SUFFIX. This fixes issues
when the OS prefers to install libraries under lib64, for example.
Co-authored-by: Joseph Huber <huberjn@outlook.com>
Summary:
The AMDGPU hack can be removed, and we no longer need to skip 90% of the
`HandleLLVMOptions` if we work around NVPTX earlier. Simplifies the
interface by removing duplicated logic and keeps the GPU targets from
being weirdly divergent on some flags.
Includes CMake files and placeholder header, library, test tool, regression
test and unit test.
The aim for this project is to create a replacement for the existing ORC
Runtime that currently resides in `llvm-project/compiler-rt/lib/orc`. The new
project will provide a superset of the original features, and the old runtime
will be removed once the new runtime is sufficiently developed.
See discussion at
https://discourse.llvm.org/t/rfc-move-orc-executor-support-into-top-level-project/81049
Append `-nostdlib++` and `-nostdinc++` flags to `CMAKE_REQUIRED_FLAGS`
only if we are actually building with Clang. These flags are also
passed to the C compiler, which is not allowed in GCC. Since CMake
implicitly performs some tests using the C compiler, this can lead
to incorrect check results. This should be safe, since FWIU we only
need them when bootstrapping Clang.
Even though we know that Clang supports these flags, we still need
to explicitly check if they work, as in some scenarios adding
`-nostdlib++` actually breaks the build. See PR #108357 for examples
of that.
Fixes#90332
Signed-off-by: Michał Górny <mgorny@gentoo.org>
