The production buildbot master apparently has not yet been restarted
since https://github.com/llvm/llvm-zorg/pull/393 landed.
This reverts commit 96d1baedefc3581b53bc4389bb171760bec6f191.
Remove the FLANG_INCLUDE_RUNTIME option which was replaced by
LLVM_ENABLE_RUNTIMES=flang-rt.
The FLANG_INCLUDE_RUNTIME option was added in #122336 which disables the
non-runtimes build instructions for the Flang runtime so they do not
conflict with the LLVM_ENABLE_RUNTIMES=flang-rt option added in #110217.
In order to not maintain multiple build instructions for the same thing,
this PR completely removes the old build instructions (effectively
forcing FLANG_INCLUDE_RUNTIME=OFF).
As per discussion in
https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571/2
we now implicitly add LLVM_ENABLE_RUNTIMES=flang-rt whenever Flang is
compiled in a bootstrapping (non-standalone) build. Because it is
possible to build Flang-RT separately, this behavior can be disabled
using `-DFLANG_ENABLE_FLANG_RT=OFF`. Also see the discussion an
implicitly adding runtimes/projects in #123964.
This patch is to set the paths for tools used in the
`export_executable_symbols` function in standalone build and set the
necessary macros for compiling the runtime source.
This is a re-apply of 083c683969b2436afdc45becadc955841f5f4d31 with a
fix for the flang runtime build.
This works the same way as LLVM_PARALLEL_COMPILE_JOBS except that it is
specific to the flang source rather than for the whole project.
Configuring with -DFLANG_PARALLEL_COMPILE_JOBS=1 would mean that there
would only ever be one flang source being compiled at a time.
Some of the flang sources require large amounts of memory to compile, so
this option can be used to avoid OOM erros when compiling those files
while still allowing the rest of the project to compile using the
maximum number of jobs.
Update flang/CMakeLists.txt
---------
Co-authored-by: Nikita Popov <github@npopov.com>
Co-authored-by: Michael Kruse <github@meinersbur.de>
Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME
mechanism. It will only become active when
`LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the
`FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not
conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is
passed, nothing changes with the current build process.
Motivation:
* Consistency with LLVM's other runtime libraries (compiler-rt, libc,
libcxx, openmp offload, ...)
* Allows compiling the runtime for multiple targets at once using the
LLVM_RUNTIME_TARGETS configuration options
* Installs the runtime into the compiler's per-target resource directory
so it can be automatically found even when cross-compiling
Also see RFC discussion at
https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
Mostly mechanical changes in preparation of extracting the Flang-RT
"subproject" in #110217. This PR intends to only move pre-existing files
to the new folder structure, with no behavioral change. Common files
(headers, testing, cmake) shared by Flang-RT and Flang remain in
`flang/`.
Some cosmetic changes and files paths were necessary:
* Relative paths to the new path for the source files and
`add_subdirectory`.
* Add the new location's include directory to `include_directories`
* The unittest/Evaluate directory has unitests for flang-rt and Flang. A
new `CMakeLists.txt` was introduced for the flang-rt tests.
* Change the `#include` paths relative to the include directive
* clang-format on the `#include` directives
* Since the paths are part if the copyright header and include guards, a
script was used to canonicalize those
* `test/Runtime` and runtime tests in `test/Driver` are moved, but the
lit.cfg.py mechanism to execute the will only be added in #110217.
1. Add a new `MLIR_DEPS` argument group to `flang_add_library()`, and
move MLIR-specific dependencies to that group. These dependencies are
added as usual in regular builds, and are skipped in standalone builds,
since MLIR targets are not visible there (and were already built and
installed).
2. Fix the value of `MLIR_MAIN_SRC_DIR` to refer to the current source
directory rather than the directory written into MLIR CMake files. The
latter refers to the directory used to build the MLIR package, and is no
longer valid.
3. Fix non-dylib friendly linking of `LLVMTargetParser` in `Optimizer`
unittests.
With these changes, I can successfully run Flang's regression tests.
MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR point to the source directory,
which is not installed. As such, the installed MLIRConfig.cmake also
should not reference it.
The comment indicates that these are needed for mlir_tablegen(), but I
don't see any related uses.
The motivation for this is the use in flang, where we end up inheriting
a meaningless MLIR_MAIN_SRC_DIR from a previous MLIR build, whose source
directory doesn't exist anymore, and that cannot be overridden with the
correct path, because it's not a cached variable.
Instead do what all the other projects do for LLVM_MAIN_SRC_DIR and
initialize MLIR_MAIN_SRC_DIR to CMAKE_CURRENT_SOURCE_DIR/../mlir.
For MLIR_INCLUDE_DIR there already is an exported MLIR_INCLUDE_DIRS,
which can be used instead.
Following the conclusion of the
[RFC](https://discourse.llvm.org/t/rfc-names-for-flang-rt-libraries/84321),
rename Flang's runtime libraries as follows:
* libFortranRuntime.(a|so) to libflang_rt.runtime.(a|so)
* libFortranFloat128Math.a to libflang_rt.quadmath.a
* libCufRuntime_cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so) to
libflang_rt.cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so)
This follows the same naming scheme as Compiler-RT libraries
(`libclang_rt.${component}.(a|so)`). It provides some consistency
between Flang's runtime libraries for current and potential future
library components.
Introduce the CMake switch FLANG_INCLUDE_RUNTIME. When set to off, do
not add build instructions for the runtime.
This is required for Flang-RT (#110217) and the current runtime CMake
code to co-exist. When using `LLVM_ENABLE_RUNTIME=flang-rt`, the in-tree
build instructions are in conflict and must be disabled.
This patch addresses post commit review comments from #124859.
The extra compile definition is not necessary and goes against the
effort to separate the runtimes from the flang compiler itself. The
function declaration for `CUFInit` can be accessed anyway since the
header are always present. The insertion of the call is only based on
the language feature options from the folding context.
A program compiled with cuda enabled but no cufruntime would just fail
at link time as expected.
This patch adds a call to the CUFInit function just after `ProgramStart`
when CUDA Fortran is enabled to initialize the CUDA context. This allows
us to set up some context information like the stack limit that can be
defined by an environment variable `ACC_OFFLOAD_STACKSIZE=<value>`.
Support discovering LLVM, Clang and MLIR via the standard CMake logic in
addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking
anyone's workflow the way #120914 did, this change explicitly introduces
two possible code paths based on variables provided:
1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is.
2. If they are not defined, `find_package()` is called normally to
discover the packages using the standard CMake logic, and the discovered
paths are added
---------
Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
The changes in #87822 introduced a regression where Flang could no
longer be built standalone without explicitly specifying all of
LLVM_DIR, CLANG_DIR and MLIR_DIR. Restore the earlier logic that used
these paths as hints, and supported finding system-wide LLVM install via
default paths. Instead, make paths absolute after locating the packages,
using the paths CMake determined.
-----
@vzakhari, could you confirm that this doesn't break your use case?
Add allocators for CUDA fortran allocation on the device. 3 allocators
are added for pinned, device and managed/unified memory allocation.
`CUFRegisterAllocator()` is called to register the allocators in the
allocator registry added in #100690.
Since this require CUDA, a cmake option `FLANG_CUF_RUNTIME` is added to
conditionally build these.
Moves definitions of the kind arrays into a Fortran MODULE to not only
emit the MOD file, but also compile that MODULE file into an object
file. This file is then linked into libFortranRuntime.so.
Eventually this workaround PR shoud be redone and a proper runtime build
should be setup that will then also compile Fortran MODULE files.
Fixes#89403
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Co-authored-by: Michael Kruse <github@meinersbur.de>
This works the same way as LLVM_PARALLEL_COMPILE_JOBS except that it is
specific to the flang source rather than for the whole project.
Configuring with -DFLANG_PARALLEL_COMPILE_JOBS=1 would mean that there
would only ever be one flang source being compiled at a time.
Some of the flang sources require large amounts of memory to compile, so
this option can be used to avoid OOM erros when compiling those files
while still allowing the rest of the project to compile using the
maximum number of jobs.
---------
Co-authored-by: Nikita Popov <github@npopov.com>
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode (`set_property(TARGET <target>
PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE
generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
Remove an extra '-D' in the call to add_compile_definitions. The extra
-D causes -D-DFLANG_RUNTIME_F128_MATH_LIB=libquadmath to appear in
compile options which results in a compilation failure. This occurs only
on systems using cmake versions 3.22.1 or 3.24.3. Using cmake 3.28.1
seems to automatically remove the duplicate -D.
Fixes https://github.com/llvm/llvm-project/pull/81971
When building flang out-of-tree with relative paths in LLVM_DIR,
CLANG_DIR and MLIR_DIR, we need to compute the absolute paths
based on the CMake build directory (i.e. where the cmake is invoked
from).
Select POSIX 2008 standard to avoid including Darwin extensions.
Otherwise, Darwin's math.h header defines HUGE, which conflicts
with Flang's HUGE function.
This started happening after 4762c6557d15 (#82443), that added the
"utility" include, which seems to include "math.h".
Implemented few entry points for REAL(16) math in FortranF128Math
static library. It is a thin wrapper around GNU libquadmath.
Flang driver can always link it, and the dependencies will
be brought in as needed.
The final Fortran program/library that uses any of the entry points
will depend on the underlying third-party library - this dependency
has to be resolved somehow. I added FLANG_RUNTIME_F128_MATH_LIB
CMake control so that the compiler driver and the runtime library
can be built using the same third-party library: this way the linker
knows which dependency to link in (under --as-needed).
The compiler distribution should specify which third-party library
is required for linking/running the apps that use REAL(16).
The compiler package may provide a version of the third-party library
or at least a stub library that can be used for linking, but
the final program execution will still require the actual library.
This makes it more convenient to install flang without using the general
`ninja install` to install everything.
To install flang-new and associated things one needs `ninja
install-flang-new install-flang-libraries install-flang-headers`.
The update stems from the discussion in
https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442
This is my third attempt at this. My second attempt was in pull request
#69121.
This is my second attempt at this. My first attempt was in pull request
#68756.
This pull request has three changes from the second one:
- I put the test into the Driver directory rather than Examples so that
it would get run without require the define LLVM_BUILD_EXAMPLES.
- When installing ISO_Fortran_binding.h, I changed the location where it
was installed from.
- I changed the test so that it would work when flang was built with
shared libraries.
Here's the information from my previous attempts:
I decided to put ISO_Fortran_binding.h in a place where it would be
accessible with the include: "#include<ISO_Fortran_binding.h>" rather
than "#include<fortran/ISO_Fortran_binding.h>" because this is what
gfortran implements.
Note that the file is also installed into ".../include/flang", so if a
user wanted to access the file from a compiler other than clang, it
would be available.
I added a test in ".../flang/test/Driver". To make the test work, I also
needed to put ISO_Fortran_binding.h into the build area.
Although the flang project depends on clang, clang may not always be
available in a flang build. For example, when building just the
"check-flang" target, the "clang" executable may not be available at the
time the new test gets run. To account for this, I made the test's
script check for the existence of the "clang" executable. If "clang" is
not available, it simply prints "PASS". If it is available, it fully
builds and executes the test. On success, this will also print "PASS"
The update stems from the discussion in
https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442
This is my second attempt at this. My first attempt was in pull request
#68756.
I decided to put ISO_Fortran_binding.h in a place where it would be
accessible with the include: "#include<ISO_Fortran_binding.h>" rather
than "#include<fortran/ISO_Fortran_binding.h>" because this is what
gfortran implements.
Note that the file is also installed into ".../include/flang", so if a
user wanted to access the file from a compiler other than clang, it
would be available.
I added a test in ".../flang/test/Examples". To make the test work, I
also needed to put ISO_Fortran_binding.h into the build area.
Although the flang project depends on clang, clang may not always be
available in a flang build. For example, when building just the
"check-flang" target, the "clang" executable may not be available at the
time the new test gets run. To account for this, I made the test's
script check for the existence of the "clang" executable. If "clang" is
not available, it simply prints "PASS". If it is available, it fully
builds and executes the test. On success, this will also print "PASS"
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
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.
Without this change the problem is that flangOmpReport and
flangPrintFunctionNames libraries are not built under 'all',
but they are imported targets via LLVMExports.cmake so that
any out-of-tree build that configures upon LLVM+Flang package
will get this CMake error:
```
The imported target "flangPrintFunctionNames" references the file
".../lib/flangPrintFunctionNames.so"
but this file does not exist.
```
flang-aarch64-out-of-tree buildbot (https://lab.llvm.org/buildbot/#/builders/175)
does not catch this issue, because it does not enable Flang on the first stage.
This change gets rid of FLANG_BUILD_EXAMPLES in favor of LLVM_BUILD_EXAMPLES
and uses available LLVM CMake macros to add example executables/libraries.
Differential Revision: https://reviews.llvm.org/D145992
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
