First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550 to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools.
Reviewed By: Ericson2314
Differential Revision: https://reviews.llvm.org/D116472
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115569
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
The preprocessor definitions __BYTE_ORDER__, __ORDER_BIG_ENDIAN__, and
__ORDER_LITTLE_ENDIAN__ are gcc extensions (also supported by clang),
but msvc (and others) do not define them. As a result __BYTE_ORDER__
and __ORDER_BIG_ENDIAN__ both evaluate to 0 by the prepreprocessor,
and __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, the first `#if` condition
to 1, hence assuming the wrong byte order for x86(_64).
This patch instead uses CMake's TestBigEndian module to determine
target architecture's endianness at configure-time.
Note this also uses the same mechanism for the runtime. If compiling
flang as a cross-compiler, the runtime for the compile-target must be
built separately (Flang does not support the LLVM_ENABLE_RUNTIMES
mechanism yet).
Fixes llvm.org/PR51597
Reviewed By: ijan1, Leporacanthicus
Differential Revision: https://reviews.llvm.org/D109108
This patch cleans-up the file generation code in Flang's frontend
driver. It improves the layering between
`CompilerInstance::CreateDefaultOutputFile`,
`CompilerInstance::CreateOutputFile` and their various clients.
* Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it
private. This method is an implementation detail.
* Instead of passing an `std::error_code` out parameter into
`CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter
and idiomatic LLVM.
* Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`)
issue an error when file creation fails. The error code from
`CreateOutputFileImpl` is used to generate a meaningful diagnostic
message.
* Remove error reporting from `PrintPreprocessedAction::ExecuteAction`.
This is only for cases when output file generation fails. This is
handled in `CreateDefaultOutputFile` instead (see the previous point).
* Inline `AddOutputFile` into its only caller,
`CreateDefaultOutputFile`.
* Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>`
for non-seekable output streams. This simplifies the logic in the driver
and was introduced for this very reason in [1]
* Moke sure that the diagnostics from the prescanner when running `-E`
(`PrintPreprocessedAction::ExecuteAction`) are printed before the actual
output is generated.
* Update comments, add test.
NOTE: This patch relands [2]. As suggested by Michael Kruse in the
post-commit/post-revert review, I've added the following:
```
config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@"
```
in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in
output-paths.f90 gets the correct value on Windows as well as on Linux.
[1] https://reviews.llvm.org/D93260
[2] fd21d1e198
Reviewed By: ashermancinelli
Differential Revision: https://reviews.llvm.org/D108390
https://reviews.llvm.org/D106137 added support for plugins in Flang. The
CMake configuration for plugins requires some LLVM variables that are
not available in out-of-tree builds (e.g. `LLVM_SHLIB_OUTPUT_INTDIR`).
This has caused the out-of-tree BuildBot worker to start failing:
* https://lab.llvm.org/buildbot/#/builders/175
This patch effectively disables plugins in out-of-tree builds and fixes
the configuration error. In order to support plugins in out-of-tree
builds, we would have to find a way to access the missing CMake
variables from LLVM. This could be implemented at a later time.
Differential Revision: https://reviews.llvm.org/D107973
Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code around using custom frontend actions from within a plugin
shared library object.
It also adds to the Driver-help test to check the help option with the
updated driver flags.
Additionally, the patch creates a plugin-example test to check the
HelloWorld plugin example runs correctly. As part of this, a new CMake
flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built
and for the test to run.
This Plugin API has only been tested on Linux.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106137
This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].
With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).
LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.
The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177
Differential Revision: https://reviews.llvm.org/D105811
As `external-hello-world` is not really a test, I am moving it from
`flang/unittest/Runtime` to `flang/examples` (it makes a lot of sense as
an example). I've not modified the source code (apart from adjusting the
include paths).
Differential Revision: https://reviews.llvm.org/D104320
For out-of-tree builds of Flang, FLANG_BUILD_NEW_DRIVER is not inherited
from llvm-project/llvm/CMakeLists.txt. Instead, a separate definition is
required (but only for out-of-tree builds).
Differential Revision: https://reviews.llvm.org/D102323
Flang's CMake modules directory was being added to the CMake module path
twice, and AddFlang was being included after the first addition. Remove
the unnecessary first addition and move the AddFlang include down to the
second one. This way, it occurs after LLVM's CMake modules have been
included for a standalone build, so it can make use of those modules.
With this patch, `FLANG_BUILD_NEW_DRIVER` is set to `On` by default
(i.e. the new driver is enabled). Note that the new driver depends on
Clang and hence with this change you will need to add `clang` to
`LLVM_ENABLE_PROJECTS`.
If you don't want to build the new driver, set `FLANG_BUILD_NEW_DRIVER`
to `Off`. This way you won't be required to include `clang` in
`LLVM_ENABLE_PROJECTS`.
Differential Revision: https://reviews.llvm.org/D101842
* Added a sanity check with `Clang_FOUND` to verify that find_package
succeeded
* Made sure that find_package won't use any of CMake's standard paths
to guarantee that only the path provided with CLANG_DIR is considered
(implemented through NO_DEFAULT_PATH)
* Made the call to get_filename_component more explicit (so that it is
clear what the base directory is)
* Updated comments to clarify what CLANG_DIR means
Differential Revision: https://reviews.llvm.org/D99088
The build was putting .mod files for intrinsic modules in
tools/flang/include/flang but the install puts them in include/flang,
as does the out-of-tree build. This confused things for the driver.
This change makes the build consistent with the install and simplifies
the flang script accordingly.
Also, clean up the cmake commands for building the .mod files.
Differential Revision: https://reviews.llvm.org/D98522
Most components required for this are already there.
Build and Testing clean.
ninja check-flang
Reviewed By: clementval, tskeith
Differential Revision: https://reviews.llvm.org/D96411
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
Flang has two CMake configurable header files that define compiler
version numbers:
* f18_version.h.in - only used in f18.cpp (uses version numbers from
LLVM's macro definitions)
* Version.inc.in - not currently used (uses version numbers hard-coded
in Flang's top CMake script)
Currently only f18_version.h.in provides version numbers consistent with
other subprojects in llvm-project. However, its location and name are
inconsistent with e.g. Clang. This patch merges the two headers
together:
* hard-coded version numbers in Flang's top CMake script are deleted
* Version.inc.in is updated to provide string versions of version
numbers (required by f18.cpp)
* f18_version.h.in is deleted as it's no longer needed
Differential Revision: https://reviews.llvm.org/D94422
Recent patch that improved Flang's compatibility with respect to how LLVM
dynamic libraries should be linked (and specified in CMake recipes),
introduced a bug in the definition of `flang-new`:
* https://reviews.llvm.org/D87893
More specifically, `add_flang_tool` does not support the
`LINK_COMPONENTS` CMake argument. Instead, one should set
`LLVM_LINK_COMPONENTS` before calling `add_flang_tool`.
This patch reverts the change for `flang-new` from
https://reviews.llvm.org/D87893, and instead:
* sets `LLVM_LINK_COMPONENTS`
* calls `clang_target_link_libraries` to add Clang dependencies
Differential Revision: https://reviews.llvm.org/D89403
Harmonize usage of LLVM components througout Flang.
Explicit LLVM Libs where used across several CMakeFIles, which led to
incompatibilities with LLVM shlibs.
Fortunately, the LLVM component system can be relied on to harmoniously handle
both cases.
Differential Revision: https://reviews.llvm.org/D87893
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
Summary:
This is the first patch implementing the new Flang driver as outlined in [1],
[2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver
(`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the
current Flang throwaway driver, `flang`, can be replaced with `flang-new`.
Currently only 2 options are supported: `-help` and `--version`.
`flang-new` is implemented in terms of libclangDriver, defaulting the driver
mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the
driver runs in Flang mode regardless of the name of the binary inferred from
argv[0].
The design of the new Flang compiler and frontend drivers is inspired by it
counterparts in Clang [3]. Currently, the new Flang compiler and frontend
drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend.
To identify Flang options, this patch adds FlangOption/FC1Option enums.
Driver::printHelp is updated so that `flang-new` prints only Flang options.
The new Flang driver is disabled by default. To enable it, set
`-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to
`LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”).
[1] “RFC: new Flang driver - next steps”
http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
[2] “RFC: Adding a fortran mode to the clang driver for flang”
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
[3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang”
http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: richard.barton.arm, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D86089
For out of tree builds, the user generally needs to specify LLVM_DIR and
MLIR_DIR on the command line so that the correct LLVM and MLIR
installations are picked up.
If the provided paths are absolute, everything works fine, however for
buildbots it is customary to work with relative paths, and that makes it
difficult for CMake to find the right modules to include.
This patch changes CMakeLists.txt to convert LLVM_DIR and MLIR_DIR to
absolute paths before adding them to CMAKE_MODULE_PATH. The inputs are
assumed to be relative to the source directory (llvm-project/flang).
Differential Revision: https://reviews.llvm.org/D87083
This applies the same fix that D84748 did for macro definitions.
Appropriate include path is now automatically set for all libraries
which link against gtest targets, which avoids the need to set
include_directories in various parts of the project.
Differential Revision: https://reviews.llvm.org/D86616
According to llvm/cmake/config-ix.cmake, gcc's potentially uninitialized
use analysis has lots of false positives. We are encountering one in
flang/lib/Lower/CharacterExpr.cpp.
That warning is disabled for gcc in in-tree builds; this does the same
thing for out-of-tree builds.
Differential Revision: https://reviews.llvm.org/D85694
Based on https://reviews.llvm.org/D84022 with additional changes to
maintain out-of-tree builds.
Original commit message:
Currently the binaries are output directly into the bin subdirectory of
the build directory. This doesn't work correctly with multi-config
generators which should output the binaries into <CONFIG_NAME>/bin
instead.
The original patch was implemented by David Truby and the additional
changes added here were also proposed by David Truby.
Differential Revision: https://reviews.llvm.org/D85078/
Co-authored-by: David Truby <david.truby@arm.com>
Summary:
Currently the binaries are output directly into the bin subdirectory of the
build directory. This doesn't work correctly with multi-config generators which
should output the binaries into <CONFIG_NAME>/bin instead.
Reviewers: sscalpone, richard.barton.arm
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84022
Summary:
As a corrollary, these tests are now run as part of the check-flang
target.
Reviewers: sscalpone
Subscribers: mgorny, delcypher, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83946
Summary:
Fix individual check tests with lit when building out-of-tree
`ninja check-flang-<folder>` was not working.
The CMakeLists.txt was looking for the lit tests in the source directory
instead of the build directory.
This commit extends @CarolineConcatto previous patch[D81002]
Reviewers: DavidTruby, sscalpone, tskeith, CarolineConcatto, jdoerfert
Reviewed By: DavidTruby
Subscribers: flang-commits, llvm-commits, CarolineConcatto
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D82120
Summary:
The only difference is that LLVM_ENABLE_WERROR is set to OFF
by default, but we enable this in a standalone flang build
This commit fixes some windows issues with the flags
Reviewers: DavidTruby, jdoerfert, sscalpone
Reviewed By: DavidTruby, sscalpone
Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D78306
Summary:
This patch removes the custom CMAKE_RELEASE_CXX_FLAGS variable.
This variable being set was having the effect of removing other important
Release flags, notably `-DNDEBUG`.
This patch may need to be accompanied by fixes for the macOS issues that
the removed comment mentions; I don't have a mac to test this on though so
hopefully a reviewer can help with that.
Reviewers: Andrzej, tskeith, sscalpone
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80794
[mlir rebase] Add MLIR config and react to MLIR name changes
Similar to flang-compiler/f18#1085. Now use the MLIR package to set up paths for include files and libraries. Three MLIR names changed:
* VectorOpsDialect to VectorDialect
* AffineOpsDialect to AffineDialect
* createVectorizePass to createSuperVectorizePass
Update README.md to explain how to link with MLIR. Update the example gcc to version 8.3.
Update drone.io config to define -DMLIR_DIR
Co-authored-by: Jean Perier <jperier@nvidia.com>
Original-commit: flang-compiler/f18@116f64315f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1090
In general all the basic functionality seems to work and removes some redundancy
and more complicated features in favor of borrowing infrastructure from LLVM
build configurations. Here's a quick summary of details and remaining issues:
* Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and
MacOS/darwin. Architectures include x86_64 and Arm. Without
access to Window nothing has been tested there yet.
* As we change file and directory naming schemes (i.e.,
capitalization) some odd things can occur on MacOS systems with
case preserving but not case senstive file system configurations.
Can be painful and certainly something to watch out for as any
any such changes continue.
* Testing infrastructure still needs to be tuned up and worked on.
Note that there do appear to be cases of some tests hanging (on
MacOS in particular). They appear unrelated to the build
process.
* Shared library configurations need testing (and probably fixing).
* Tested both standalone and 'in-mono repo' builds. Changes for
supporting the mono repo builds will require LLVM-level changes that
are straightforward when the time comes.
* The configuration contains a work-around for LLVM's C++ standard mode
passing down into Flang/F18 builds (i.e., LLVM CMake configuration would
force a -std=c++11 flag to show up in command line arguments. The
current configuration removes that automatically and is more strict in
following new CMake guidelines for enforcing C++17 mode across all the
CMake files.
* Cleaned up a lot of repetition in the command line arguments. It
is likely that more work is still needed to both allow for
customization and working around CMake defailts (or those
inherited from LLVM's configuration files). On some platforms agressive
optimization flags (e.g. -O3) can actually break builds due to the inlining
of templates in .cpp source files that then no longer are available for use
cases outside those source files (shows up as link errors). Sticking at -O2
appears to fix this. Currently this CMake configuration forces this in
release mode but at the cost of stomping on any CMake, or user customized,
settings for the release flags.
* Made the lit tests non-source directory dependent where appropriate. This is
done by configuring certain test shell files to refer to the correct paths
whether an in or out of tree build is being performed. These configured
files are output in the build directory. A %B substitution is introduced in
lit to refer to the build directory, mirroring the %S substitution for the
source directory, so that the tests can refer to the configured shell scripts.
Co-authored-by: David Truby <david.truby@arm.com>
Original-commit: flang-compiler/f18@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
Some of the regression tests are C programs that act as test harnesses
for the compiler internals as opposed to being Fortran inputs to test
the compiler in action. The former style of tests are analog to LLVM's
unittests and will not use the lit framework.
Change-Id: I0ff10e23f66ff843e8fff4c35cfb6559b9dab762
Original-commit: flang-compiler/f18@2bfddbe8f8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1027
Tree-same-pre-rewrite: false
Adds FIR library that implements an MLIR dialect to which Fortran
parse-tree will be lowered to.
FIR is defined and documented inside FIROps.td added in this commit.
It is possible to generate a more readable description FIRLangRef.md
from FIROps.td following the related instructions added to the README.md
by this commit.
This patch adds FIR definition and implementation that allow parsing,
printing, and verifying FIR. FIR transformations and lowering to Standard
and LLVM dialects are not part of this patch. The FIR verifiers are verifying
the basic properties of FIR operations in order to provide a sufficient
frame for lowering. Verifiers for more advanced FIR properties can be added
as needed.
Coarrays are not covered by FIR defined in this patch.
This patch also adds tco tool that is meant to process FIR input files and
drives transformations on it. The tco tool is used for testing.
In this patch, it is only used to demonstrate parsing/verifying/
and dumping FIR with round-trip tests.
Note:
This commit does not reflect an actual work log, it is a feature-based split of the
changes done in the FIR experimental branch. The related work log can be found in the
commits between:
742edde572
and
2ff5524212
Changes on top of these original commits were made during this patch review.
Original-commit: flang-compiler/f18@30b428a51e
Reviewed-on: https://github.com/flang-compiler/f18/pull/1035
John Ericson