llvm-project/flang/lib/Frontend/CompilerInvocation.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1017 lines
38 KiB
C++
Raw Normal View History

[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
//===- CompilerInvocation.cpp ---------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// Coding style: https://mlir.llvm.org/getting_started/DeveloperGuide/
//
//===----------------------------------------------------------------------===//
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
#include "flang/Frontend/CompilerInvocation.h"
#include "flang/Common/Fortran-features.h"
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
#include "flang/Frontend/CodeGenOptions.h"
#include "flang/Frontend/PreprocessorOptions.h"
#include "flang/Frontend/TargetOptions.h"
#include "flang/Semantics/semantics.h"
#include "flang/Version.inc"
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
#include "clang/Basic/AllDiagnostics.h"
#include "clang/Basic/DiagnosticDriver.h"
#include "clang/Basic/DiagnosticOptions.h"
#include "clang/Driver/DriverDiagnostic.h"
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
#include "clang/Driver/OptionUtils.h"
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
#include "clang/Driver/Options.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/StringSwitch.h"
#include "llvm/Option/Arg.h"
#include "llvm/Option/ArgList.h"
#include "llvm/Option/OptTable.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/FileUtilities.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/Process.h"
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
#include "llvm/TargetParser/Triple.h"
#include <memory>
#include <optional>
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
using namespace Fortran::frontend;
//===----------------------------------------------------------------------===//
// Initialization.
//===----------------------------------------------------------------------===//
CompilerInvocationBase::CompilerInvocationBase()
: diagnosticOpts(new clang::DiagnosticOptions()),
preprocessorOpts(new PreprocessorOptions()) {}
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
CompilerInvocationBase::CompilerInvocationBase(const CompilerInvocationBase &x)
: diagnosticOpts(new clang::DiagnosticOptions(x.getDiagnosticOpts())),
preprocessorOpts(new PreprocessorOptions(x.getPreprocessorOpts())) {}
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
CompilerInvocationBase::~CompilerInvocationBase() = default;
//===----------------------------------------------------------------------===//
// Deserialization (from args)
//===----------------------------------------------------------------------===//
[flang][Driver] Refine _when_ driver diagnostics are formatted This patch refines //when// driver diagnostics are formatted so that `flang-new` and `flang-new -fc1` behave consistently with `clang` and `clang -cc1`, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: ``` $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Before this change, none of the above would be formatted. Note also that the default behaviour in `flang-new` is different to `flang-new -fc1` (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling `getLastArg` rather than in driver.cpp. In Clang's Options.td, `defm color_diagnostics` is replaced with two separate definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in `clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't re-use `OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164
2022-06-22 23:56:34 +08:00
static bool parseShowColorsArgs(const llvm::opt::ArgList &args,
bool defaultColor = true) {
// Color diagnostics default to auto ("on" if terminal supports) in the
// compiler driver `flang-new` but default to off in the frontend driver
// `flang-new -fc1`, needing an explicit OPT_fdiagnostics_color.
// Support both clang's -f[no-]color-diagnostics and gcc's
// -f[no-]diagnostics-colors[=never|always|auto].
enum {
Colors_On,
Colors_Off,
Colors_Auto
} showColors = defaultColor ? Colors_Auto : Colors_Off;
for (auto *a : args) {
const llvm::opt::Option &opt = a->getOption();
if (opt.matches(clang::driver::options::OPT_fcolor_diagnostics)) {
showColors = Colors_On;
} else if (opt.matches(clang::driver::options::OPT_fno_color_diagnostics)) {
showColors = Colors_Off;
} else if (opt.matches(clang::driver::options::OPT_fdiagnostics_color_EQ)) {
llvm::StringRef value(a->getValue());
if (value == "always")
showColors = Colors_On;
else if (value == "never")
showColors = Colors_Off;
else if (value == "auto")
showColors = Colors_Auto;
}
}
return showColors == Colors_On ||
(showColors == Colors_Auto &&
llvm::sys::Process::StandardErrHasColors());
}
/// Extracts the optimisation level from \a args.
static unsigned getOptimizationLevel(llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
unsigned defaultOpt = llvm::CodeGenOpt::None;
if (llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_O_Group)) {
if (a->getOption().matches(clang::driver::options::OPT_O0))
return llvm::CodeGenOpt::None;
assert(a->getOption().matches(clang::driver::options::OPT_O));
return getLastArgIntValue(args, clang::driver::options::OPT_O, defaultOpt,
diags);
}
return defaultOpt;
}
bool Fortran::frontend::parseDiagnosticArgs(clang::DiagnosticOptions &opts,
[flang][Driver] Refine _when_ driver diagnostics are formatted This patch refines //when// driver diagnostics are formatted so that `flang-new` and `flang-new -fc1` behave consistently with `clang` and `clang -cc1`, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: ``` $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Before this change, none of the above would be formatted. Note also that the default behaviour in `flang-new` is different to `flang-new -fc1` (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling `getLastArg` rather than in driver.cpp. In Clang's Options.td, `defm color_diagnostics` is replaced with two separate definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in `clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't re-use `OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164
2022-06-22 23:56:34 +08:00
llvm::opt::ArgList &args) {
opts.ShowColors = parseShowColorsArgs(args);
return true;
}
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
static void parseCodeGenArgs(Fortran::frontend::CodeGenOptions &opts,
llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
opts.OptimizationLevel = getOptimizationLevel(args, diags);
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
if (args.hasFlag(clang::driver::options::OPT_fdebug_pass_manager,
clang::driver::options::OPT_fno_debug_pass_manager, false))
opts.DebugPassManager = 1;
if (args.hasFlag(clang::driver::options::OPT_fstack_arrays,
clang::driver::options::OPT_fno_stack_arrays, false)) {
opts.StackArrays = 1;
}
for (auto *a : args.filtered(clang::driver::options::OPT_fpass_plugin_EQ))
opts.LLVMPassPlugins.push_back(a->getValue());
// -fembed-offload-object option
for (auto *a :
args.filtered(clang::driver::options::OPT_fembed_offload_object_EQ))
opts.OffloadObjects.push_back(a->getValue());
// -flto=full/thin option.
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_flto_EQ)) {
llvm::StringRef s = a->getValue();
assert((s == "full" || s == "thin") && "Unknown LTO mode.");
if (s == "full")
opts.PrepareForFullLTO = true;
else
opts.PrepareForThinLTO = true;
}
if (auto *a = args.getLastArg(clang::driver::options::OPT_save_temps_EQ))
opts.SaveTempsDir = a->getValue();
// -mrelocation-model option.
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_mrelocation_model)) {
llvm::StringRef modelName = a->getValue();
auto relocModel =
llvm::StringSwitch<std::optional<llvm::Reloc::Model>>(modelName)
.Case("static", llvm::Reloc::Static)
.Case("pic", llvm::Reloc::PIC_)
.Case("dynamic-no-pic", llvm::Reloc::DynamicNoPIC)
.Case("ropi", llvm::Reloc::ROPI)
.Case("rwpi", llvm::Reloc::RWPI)
.Case("ropi-rwpi", llvm::Reloc::ROPI_RWPI)
.Default(std::nullopt);
if (relocModel.has_value())
opts.setRelocationModel(*relocModel);
else
diags.Report(clang::diag::err_drv_invalid_value)
<< a->getAsString(args) << modelName;
}
// -pic-level and -pic-is-pie option.
if (int picLevel = getLastArgIntValue(
args, clang::driver::options::OPT_pic_level, 0, diags)) {
if (picLevel > 2)
diags.Report(clang::diag::err_drv_invalid_value)
<< args.getLastArg(clang::driver::options::OPT_pic_level)
->getAsString(args)
<< picLevel;
opts.PICLevel = picLevel;
if (args.hasArg(clang::driver::options::OPT_pic_is_pie))
opts.IsPIE = 1;
}
// This option is compatible with -f[no-]underscoring in gfortran.
if (args.hasFlag(clang::driver::options::OPT_fno_underscoring,
clang::driver::options::OPT_funderscoring, false)) {
opts.Underscoring = 0;
}
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
}
/// Parses all target input arguments and populates the target
/// options accordingly.
///
/// \param [in] opts The target options instance to update
/// \param [in] args The list of input arguments (from the compiler invocation)
static void parseTargetArgs(TargetOptions &opts, llvm::opt::ArgList &args) {
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_triple))
opts.triple = a->getValue();
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_target_cpu))
opts.cpu = a->getValue();
for (const llvm::opt::Arg *currentArg :
args.filtered(clang::driver::options::OPT_target_feature))
opts.featuresAsWritten.emplace_back(currentArg->getValue());
}
// Tweak the frontend configuration based on the frontend action
static void setUpFrontendBasedOnAction(FrontendOptions &opts) {
if (opts.programAction == DebugDumpParsingLog)
opts.instrumentedParse = true;
if (opts.programAction == DebugDumpProvenance ||
opts.programAction == Fortran::frontend::GetDefinition)
opts.needProvenanceRangeToCharBlockMappings = true;
}
/// Parse the argument specified for the -fconvert=<value> option
static std::optional<const char *> parseConvertArg(const char *s) {
return llvm::StringSwitch<std::optional<const char *>>(s)
.Case("unknown", "UNKNOWN")
.Case("native", "NATIVE")
.Case("little-endian", "LITTLE_ENDIAN")
.Case("big-endian", "BIG_ENDIAN")
.Case("swap", "SWAP")
.Default(std::nullopt);
}
static bool parseFrontendArgs(FrontendOptions &opts, llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
unsigned numErrorsBefore = diags.getNumErrors();
// By default the frontend driver creates a ParseSyntaxOnly action.
opts.programAction = ParseSyntaxOnly;
// Treat multiple action options as an invocation error. Note that `clang
// -cc1` does accept multiple action options, but will only consider the
// rightmost one.
if (args.hasMultipleArgs(clang::driver::options::OPT_Action_Group)) {
const unsigned diagID = diags.getCustomDiagID(
clang::DiagnosticsEngine::Error, "Only one action option is allowed");
diags.Report(diagID);
return false;
}
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// Identify the action (i.e. opts.ProgramAction)
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_Action_Group)) {
switch (a->getOption().getID()) {
default: {
llvm_unreachable("Invalid option in group!");
}
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
case clang::driver::options::OPT_test_io:
opts.programAction = InputOutputTest;
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
break;
case clang::driver::options::OPT_E:
opts.programAction = PrintPreprocessedInput;
break;
case clang::driver::options::OPT_fsyntax_only:
opts.programAction = ParseSyntaxOnly;
break;
case clang::driver::options::OPT_emit_mlir:
opts.programAction = EmitMLIR;
break;
case clang::driver::options::OPT_emit_llvm:
opts.programAction = EmitLLVM;
break;
case clang::driver::options::OPT_emit_llvm_bc:
opts.programAction = EmitLLVMBitcode;
break;
[flang][driver] Add support for `-c` and `-emit-obj` This patch adds a frontend action for emitting object files. While Flang does not support code-generation, this action remains a placeholder. This patch simply provides glue-code to connect the compiler driver with the appropriate frontend action. The new action is triggered with the `-c` compiler driver flag, i.e. `flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`, so `-emit-obj` has to be marked as supported as well. As code-generation is not available yet, `flang-new -c` results in a driver error: ``` error: code-generation is not available yet ``` Hopefully this will help communicating the level of available functionality within Flang. The definition of `emit-obj` is updated so that it can be shared between Clang and Flang. As the original definition was enclosed within a Clang-specific TableGen `let` statement, it is extracted into a new `let` statement. That felt like the cleanest option. I also commented out `-triple` in Flang::ConstructJob and updated some comments there. This is similar to https://reviews.llvm.org/D93027. I wanted to make sure that it's clear that we can't support `-triple` until we have code-generation. However, once code-generation is available we _will need_ `-triple`. As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and is deleted. Instead, phases.f90 is added to demonstrate that users can control compilation phases (indeed, `-c` is a phase control flag). Reviewed By: SouraVX, clementval Differential Revision: https://reviews.llvm.org/D93301
2021-01-07 09:08:54 +00:00
case clang::driver::options::OPT_emit_obj:
opts.programAction = EmitObj;
[flang][driver] Add support for `-c` and `-emit-obj` This patch adds a frontend action for emitting object files. While Flang does not support code-generation, this action remains a placeholder. This patch simply provides glue-code to connect the compiler driver with the appropriate frontend action. The new action is triggered with the `-c` compiler driver flag, i.e. `flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`, so `-emit-obj` has to be marked as supported as well. As code-generation is not available yet, `flang-new -c` results in a driver error: ``` error: code-generation is not available yet ``` Hopefully this will help communicating the level of available functionality within Flang. The definition of `emit-obj` is updated so that it can be shared between Clang and Flang. As the original definition was enclosed within a Clang-specific TableGen `let` statement, it is extracted into a new `let` statement. That felt like the cleanest option. I also commented out `-triple` in Flang::ConstructJob and updated some comments there. This is similar to https://reviews.llvm.org/D93027. I wanted to make sure that it's clear that we can't support `-triple` until we have code-generation. However, once code-generation is available we _will need_ `-triple`. As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and is deleted. Instead, phases.f90 is added to demonstrate that users can control compilation phases (indeed, `-c` is a phase control flag). Reviewed By: SouraVX, clementval Differential Revision: https://reviews.llvm.org/D93301
2021-01-07 09:08:54 +00:00
break;
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
case clang::driver::options::OPT_S:
opts.programAction = EmitAssembly;
break;
case clang::driver::options::OPT_fdebug_unparse:
opts.programAction = DebugUnparse;
break;
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
case clang::driver::options::OPT_fdebug_unparse_no_sema:
opts.programAction = DebugUnparseNoSema;
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
break;
case clang::driver::options::OPT_fdebug_unparse_with_symbols:
opts.programAction = DebugUnparseWithSymbols;
break;
case clang::driver::options::OPT_fdebug_dump_symbols:
opts.programAction = DebugDumpSymbols;
break;
case clang::driver::options::OPT_fdebug_dump_parse_tree:
opts.programAction = DebugDumpParseTree;
break;
case clang::driver::options::OPT_fdebug_dump_pft:
opts.programAction = DebugDumpPFT;
break;
case clang::driver::options::OPT_fdebug_dump_all:
opts.programAction = DebugDumpAll;
break;
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
case clang::driver::options::OPT_fdebug_dump_parse_tree_no_sema:
opts.programAction = DebugDumpParseTreeNoSema;
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
break;
case clang::driver::options::OPT_fdebug_dump_provenance:
opts.programAction = DebugDumpProvenance;
break;
case clang::driver::options::OPT_fdebug_dump_parsing_log:
opts.programAction = DebugDumpParsingLog;
break;
case clang::driver::options::OPT_fdebug_measure_parse_tree:
opts.programAction = DebugMeasureParseTree;
break;
case clang::driver::options::OPT_fdebug_pre_fir_tree:
opts.programAction = DebugPreFIRTree;
break;
case clang::driver::options::OPT_fget_symbols_sources:
opts.programAction = GetSymbolsSources;
break;
case clang::driver::options::OPT_fget_definition:
opts.programAction = GetDefinition;
break;
case clang::driver::options::OPT_init_only:
opts.programAction = InitOnly;
break;
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// TODO:
// case clang::driver::options::OPT_emit_llvm:
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// case clang::driver::options::OPT_emit_llvm_only:
// case clang::driver::options::OPT_emit_codegen_only:
// case clang::driver::options::OPT_emit_module:
// (...)
}
// Parse the values provided with `-fget-definition` (there should be 3
// integers)
if (llvm::opt::OptSpecifier(a->getOption().getID()) ==
clang::driver::options::OPT_fget_definition) {
unsigned optVals[3] = {0, 0, 0};
for (unsigned i = 0; i < 3; i++) {
llvm::StringRef val = a->getValue(i);
if (val.getAsInteger(10, optVals[i])) {
// A non-integer was encountered - that's an error.
diags.Report(clang::diag::err_drv_invalid_value)
<< a->getOption().getName() << val;
break;
}
}
opts.getDefVals.line = optVals[0];
opts.getDefVals.startColumn = optVals[1];
opts.getDefVals.endColumn = optVals[2];
}
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
}
// Parsing -load <dsopath> option and storing shared object path
if (llvm::opt::Arg *a = args.getLastArg(clang::driver::options::OPT_load)) {
opts.plugins.push_back(a->getValue());
}
// Parsing -plugin <name> option and storing plugin name and setting action
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_plugin)) {
opts.programAction = PluginAction;
opts.actionName = a->getValue();
}
opts.outputFile = args.getLastArgValue(clang::driver::options::OPT_o);
opts.showHelp = args.hasArg(clang::driver::options::OPT_help);
opts.showVersion = args.hasArg(clang::driver::options::OPT_version);
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// Get the input kind (from the value passed via `-x`)
InputKind dashX(Language::Unknown);
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_x)) {
llvm::StringRef xValue = a->getValue();
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// Principal languages.
dashX = llvm::StringSwitch<InputKind>(xValue)
// Flang does not differentiate between pre-processed and not
// pre-processed inputs.
.Case("f95", Language::Fortran)
.Case("f95-cpp-input", Language::Fortran)
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
.Default(Language::Unknown);
// Flang's intermediate representations.
if (dashX.isUnknown())
dashX = llvm::StringSwitch<InputKind>(xValue)
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
.Case("ir", Language::LLVM_IR)
.Case("fir", Language::MLIR)
.Case("mlir", Language::MLIR)
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
.Default(Language::Unknown);
if (dashX.isUnknown())
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
diags.Report(clang::diag::err_drv_invalid_value)
<< a->getAsString(args) << a->getValue();
}
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
// Collect the input files and save them in our instance of FrontendOptions.
std::vector<std::string> inputs =
args.getAllArgValues(clang::driver::options::OPT_INPUT);
opts.inputs.clear();
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
if (inputs.empty())
// '-' is the default input if none is given.
inputs.push_back("-");
for (unsigned i = 0, e = inputs.size(); i != e; ++i) {
InputKind ik = dashX;
if (ik.isUnknown()) {
ik = FrontendOptions::getInputKindForExtension(
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
llvm::StringRef(inputs[i]).rsplit('.').second);
if (ik.isUnknown())
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
ik = Language::Unknown;
if (i == 0)
dashX = ik;
}
opts.inputs.emplace_back(std::move(inputs[i]), ik);
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
}
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
// Set fortranForm based on options -ffree-form and -ffixed-form.
if (const auto *arg =
args.getLastArg(clang::driver::options::OPT_ffixed_form,
clang::driver::options::OPT_ffree_form)) {
opts.fortranForm =
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
arg->getOption().matches(clang::driver::options::OPT_ffixed_form)
? FortranForm::FixedForm
: FortranForm::FreeForm;
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
}
// Set fixedFormColumns based on -ffixed-line-length=<value>
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
if (const auto *arg =
args.getLastArg(clang::driver::options::OPT_ffixed_line_length_EQ)) {
llvm::StringRef argValue = llvm::StringRef(arg->getValue());
std::int64_t columns = -1;
if (argValue == "none") {
columns = 0;
} else if (argValue.getAsInteger(/*Radix=*/10, columns)) {
columns = -1;
}
if (columns < 0) {
diags.Report(clang::diag::err_drv_negative_columns)
<< arg->getOption().getName() << arg->getValue();
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
} else if (columns == 0) {
opts.fixedFormColumns = 1000000;
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
} else if (columns < 7) {
diags.Report(clang::diag::err_drv_small_columns)
<< arg->getOption().getName() << arg->getValue() << "7";
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
} else {
opts.fixedFormColumns = columns;
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
}
}
// Set conversion based on -fconvert=<value>
if (const auto *arg =
args.getLastArg(clang::driver::options::OPT_fconvert_EQ)) {
const char *argValue = arg->getValue();
if (auto convert = parseConvertArg(argValue))
opts.envDefaults.push_back({"FORT_CONVERT", *convert});
else
diags.Report(clang::diag::err_drv_invalid_value)
<< arg->getAsString(args) << argValue;
}
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -f{no-}implicit-none
opts.features.Enable(
Fortran::common::LanguageFeature::ImplicitNoneTypeAlways,
args.hasFlag(clang::driver::options::OPT_fimplicit_none,
clang::driver::options::OPT_fno_implicit_none, false));
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -f{no-}backslash
opts.features.Enable(Fortran::common::LanguageFeature::BackslashEscapes,
args.hasFlag(clang::driver::options::OPT_fbackslash,
clang::driver::options::OPT_fno_backslash,
false));
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -f{no-}logical-abbreviations
opts.features.Enable(
Fortran::common::LanguageFeature::LogicalAbbreviations,
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
args.hasFlag(clang::driver::options::OPT_flogical_abbreviations,
clang::driver::options::OPT_fno_logical_abbreviations,
false));
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -f{no-}xor-operator
opts.features.Enable(
Fortran::common::LanguageFeature::XOROperator,
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
args.hasFlag(clang::driver::options::OPT_fxor_operator,
clang::driver::options::OPT_fno_xor_operator, false));
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -fno-automatic
if (args.hasArg(clang::driver::options::OPT_fno_automatic)) {
opts.features.Enable(Fortran::common::LanguageFeature::DefaultSave);
}
if (args.hasArg(
clang::driver::options::OPT_falternative_parameter_statement)) {
opts.features.Enable(Fortran::common::LanguageFeature::OldStyleParameter);
}
if (const llvm::opt::Arg *arg =
args.getLastArg(clang::driver::options::OPT_finput_charset_EQ)) {
llvm::StringRef argValue = arg->getValue();
if (argValue == "utf-8") {
opts.encoding = Fortran::parser::Encoding::UTF_8;
} else if (argValue == "latin-1") {
opts.encoding = Fortran::parser::Encoding::LATIN_1;
} else {
diags.Report(clang::diag::err_drv_invalid_value)
<< arg->getAsString(args) << argValue;
}
}
setUpFrontendBasedOnAction(opts);
opts.dashX = dashX;
return diags.getNumErrors() == numErrorsBefore;
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
}
// Generate the path to look for intrinsic modules
static std::string getIntrinsicDir() {
// TODO: Find a system independent API
llvm::SmallString<128> driverPath;
driverPath.assign(llvm::sys::fs::getMainExecutable(nullptr, nullptr));
llvm::sys::path::remove_filename(driverPath);
driverPath.append("/../include/flang/");
return std::string(driverPath);
}
// Generate the path to look for OpenMP headers
static std::string getOpenMPHeadersDir() {
llvm::SmallString<128> includePath;
includePath.assign(llvm::sys::fs::getMainExecutable(nullptr, nullptr));
llvm::sys::path::remove_filename(includePath);
includePath.append("/../include/flang/OpenMP/");
return std::string(includePath);
}
/// Parses all preprocessor input arguments and populates the preprocessor
/// options accordingly.
///
/// \param [in] opts The preprocessor options instance
/// \param [out] args The list of input arguments
static void parsePreprocessorArgs(Fortran::frontend::PreprocessorOptions &opts,
llvm::opt::ArgList &args) {
// Add macros from the command line.
for (const auto *currentArg : args.filtered(clang::driver::options::OPT_D,
clang::driver::options::OPT_U)) {
if (currentArg->getOption().matches(clang::driver::options::OPT_D)) {
opts.addMacroDef(currentArg->getValue());
} else {
opts.addMacroUndef(currentArg->getValue());
}
}
// Add the ordered list of -I's.
for (const auto *currentArg : args.filtered(clang::driver::options::OPT_I))
opts.searchDirectoriesFromDashI.emplace_back(currentArg->getValue());
// Prepend the ordered list of -intrinsic-modules-path
// to the default location to search.
for (const auto *currentArg :
args.filtered(clang::driver::options::OPT_fintrinsic_modules_path))
opts.searchDirectoriesFromIntrModPath.emplace_back(currentArg->getValue());
[flang][driver] Add support for `-cpp/-nocpp` This patch adds support for the `-cpp` and `-nocpp` flags. The implemented semantics match f18 (i.e. the "throwaway" driver), but are different to gfortran. In Flang the preprocessor is always run. Instead, `-cpp/-nocpp` are used to control whether predefined and command-line preprocessor macro definitions are enabled or not. In practice this is sufficient to model gfortran`s `-cpp/-nocpp`. In the absence of `-cpp/-nocpp`, the driver will use the extension of the input file to decide whether to include the standard macro predefinitions. gfortran's documentation [1] was used to decide which file extension to use for this. The logic mentioned above was added in FrontendAction::BeginSourceFile. That's relatively late in the driver set-up, but this roughly where the name of the input file becomes available. The logic for deciding between fixed and free form works in a similar way and was also moved to FrontendAction::BeginSourceFile for consistency (and to reduce code-duplication). The `-cpp/-nocpp` flags are respected also when the input is read from stdin. This is different to: * gfortran (behaves as if `-cpp` was used) * f18 (behaves as if `-nocpp` was used) Starting with this patch, file extensions are significant and some test files had to be renamed to reflect that. Where possible, preprocessor tests were updated so that they can be shared between `f18` and `flang-new`. This was implemented on top of adding new test for `-cpp/-nocpp`. [1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D99292
2021-04-07 11:42:37 +00:00
// -cpp/-nocpp
if (const auto *currentArg = args.getLastArg(
clang::driver::options::OPT_cpp, clang::driver::options::OPT_nocpp))
opts.macrosFlag =
[flang][driver] Add support for `-cpp/-nocpp` This patch adds support for the `-cpp` and `-nocpp` flags. The implemented semantics match f18 (i.e. the "throwaway" driver), but are different to gfortran. In Flang the preprocessor is always run. Instead, `-cpp/-nocpp` are used to control whether predefined and command-line preprocessor macro definitions are enabled or not. In practice this is sufficient to model gfortran`s `-cpp/-nocpp`. In the absence of `-cpp/-nocpp`, the driver will use the extension of the input file to decide whether to include the standard macro predefinitions. gfortran's documentation [1] was used to decide which file extension to use for this. The logic mentioned above was added in FrontendAction::BeginSourceFile. That's relatively late in the driver set-up, but this roughly where the name of the input file becomes available. The logic for deciding between fixed and free form works in a similar way and was also moved to FrontendAction::BeginSourceFile for consistency (and to reduce code-duplication). The `-cpp/-nocpp` flags are respected also when the input is read from stdin. This is different to: * gfortran (behaves as if `-cpp` was used) * f18 (behaves as if `-nocpp` was used) Starting with this patch, file extensions are significant and some test files had to be renamed to reflect that. Where possible, preprocessor tests were updated so that they can be shared between `f18` and `flang-new`. This was implemented on top of adding new test for `-cpp/-nocpp`. [1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D99292
2021-04-07 11:42:37 +00:00
(currentArg->getOption().matches(clang::driver::options::OPT_cpp))
? PPMacrosFlag::Include
: PPMacrosFlag::Exclude;
opts.noReformat = args.hasArg(clang::driver::options::OPT_fno_reformat);
opts.noLineDirectives = args.hasArg(clang::driver::options::OPT_P);
}
/// Parses all semantic related arguments and populates the variables
/// options accordingly. Returns false if new errors are generated.
static bool parseSemaArgs(CompilerInvocation &res, llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
unsigned numErrorsBefore = diags.getNumErrors();
// -J/module-dir option
auto moduleDirList =
args.getAllArgValues(clang::driver::options::OPT_module_dir);
// User can only specify -J/-module-dir once
// https://gcc.gnu.org/onlinedocs/gfortran/Directory-Options.html
if (moduleDirList.size() > 1) {
const unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"Only one '-module-dir/-J' option allowed");
diags.Report(diagID);
}
if (moduleDirList.size() == 1)
res.setModuleDir(moduleDirList[0]);
// -fdebug-module-writer option
if (args.hasArg(clang::driver::options::OPT_fdebug_module_writer)) {
res.setDebugModuleDir(true);
}
// -module-suffix
if (const auto *moduleSuffix =
args.getLastArg(clang::driver::options::OPT_module_suffix)) {
res.setModuleFileSuffix(moduleSuffix->getValue());
}
[flang][driver] Refactor boolean options For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought to be using TableGen multi-classes. This way, we only have to write one definition to have both forms auto-generated. This patch refactors all of Flang's boolean options to use two new multi-classes: `OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also simplified the processing of the updated options in CompilerInvocation.cpp. With the new approach, "empty" help text (i.e. no `HelpText`) is now replaced with an empty string (i.e. HelpText<"">). When running flang-new --help, that's considered as non-empty help messages, which is then printed (that's controlled by `printHelp` from llvm/lib/Option/OptTable.cpp). This means that with this patch, flang-new --help will start printing e.g. -fno-backslash, even though there is no actual help text to print for this option (apart from the empty string ""). Tests are updated accordingly. Note that with this patch, both `-fxor-operator` and `-fno-xor-operator` (and other boolean options refactored here) remain available in `flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a forthcoming patch, I will refine this so that `flang-new -fc1` only accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`). For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as `OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is an NFC from Clang's perspective. Differential Revision: https://reviews.llvm.org/D105881
2021-06-30 10:57:48 +00:00
// -f{no-}analyzed-objects-for-unparse
res.setUseAnalyzedObjectsForUnparse(args.hasFlag(
clang::driver::options::OPT_fanalyzed_objects_for_unparse,
clang::driver::options::OPT_fno_analyzed_objects_for_unparse, true));
return diags.getNumErrors() == numErrorsBefore;
}
/// Parses all diagnostics related arguments and populates the variables
/// options accordingly. Returns false if new errors are generated.
static bool parseDiagArgs(CompilerInvocation &res, llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
unsigned numErrorsBefore = diags.getNumErrors();
// -Werror option
// TODO: Currently throws a Diagnostic for anything other than -W<error>,
// this has to change when other -W<opt>'s are supported.
if (args.hasArg(clang::driver::options::OPT_W_Joined)) {
const auto &wArgs =
args.getAllArgValues(clang::driver::options::OPT_W_Joined);
for (const auto &wArg : wArgs) {
if (wArg == "error") {
res.setWarnAsErr(true);
} else {
const unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"Only `-Werror` is supported currently.");
diags.Report(diagID);
}
}
}
[flang][Driver] Refine _when_ driver diagnostics are formatted This patch refines //when// driver diagnostics are formatted so that `flang-new` and `flang-new -fc1` behave consistently with `clang` and `clang -cc1`, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: ``` $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Before this change, none of the above would be formatted. Note also that the default behaviour in `flang-new` is different to `flang-new -fc1` (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling `getLastArg` rather than in driver.cpp. In Clang's Options.td, `defm color_diagnostics` is replaced with two separate definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in `clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't re-use `OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164
2022-06-22 23:56:34 +08:00
// Default to off for `flang-new -fc1`.
res.getFrontendOpts().showColors =
parseShowColorsArgs(args, /*defaultDiagColor=*/false);
return diags.getNumErrors() == numErrorsBefore;
}
/// Parses all Dialect related arguments and populates the variables
/// options accordingly. Returns false if new errors are generated.
static bool parseDialectArgs(CompilerInvocation &res, llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
unsigned numErrorsBefore = diags.getNumErrors();
// -fdefault* family
if (args.hasArg(clang::driver::options::OPT_fdefault_real_8)) {
res.getDefaultKinds().set_defaultRealKind(8);
res.getDefaultKinds().set_doublePrecisionKind(16);
}
if (args.hasArg(clang::driver::options::OPT_fdefault_integer_8)) {
res.getDefaultKinds().set_defaultIntegerKind(8);
res.getDefaultKinds().set_subscriptIntegerKind(8);
res.getDefaultKinds().set_sizeIntegerKind(8);
}
if (args.hasArg(clang::driver::options::OPT_fdefault_double_8)) {
if (!args.hasArg(clang::driver::options::OPT_fdefault_real_8)) {
// -fdefault-double-8 has to be used with -fdefault-real-8
// to be compatible with gfortran
const unsigned diagID = diags.getCustomDiagID(
clang::DiagnosticsEngine::Error,
"Use of `-fdefault-double-8` requires `-fdefault-real-8`");
diags.Report(diagID);
}
// https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
res.getDefaultKinds().set_doublePrecisionKind(8);
}
if (args.hasArg(clang::driver::options::OPT_flarge_sizes))
res.getDefaultKinds().set_sizeIntegerKind(8);
// -fopenmp and -fopenacc
if (args.hasArg(clang::driver::options::OPT_fopenacc)) {
res.getFrontendOpts().features.Enable(
Fortran::common::LanguageFeature::OpenACC);
}
if (args.hasArg(clang::driver::options::OPT_fopenmp)) {
res.getFrontendOpts().features.Enable(
Fortran::common::LanguageFeature::OpenMP);
if (args.hasArg(clang::driver::options::OPT_fopenmp_is_device)) {
res.getLangOpts().OpenMPIsDevice = 1;
}
}
// -pedantic
if (args.hasArg(clang::driver::options::OPT_pedantic)) {
res.setEnableConformanceChecks();
}
// -std=f2018 (currently this implies -pedantic)
// TODO: Set proper options when more fortran standards
// are supported.
if (args.hasArg(clang::driver::options::OPT_std_EQ)) {
auto standard = args.getLastArgValue(clang::driver::options::OPT_std_EQ);
// We only allow f2018 as the given standard
if (standard.equals("f2018")) {
res.setEnableConformanceChecks();
} else {
const unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"Only -std=f2018 is allowed currently.");
diags.Report(diagID);
}
}
return diags.getNumErrors() == numErrorsBefore;
}
/// Parses all floating point related arguments and populates the
/// CompilerInvocation accordingly.
/// Returns false if new errors are generated.
///
/// \param [out] invoc Stores the processed arguments
/// \param [in] args The compiler invocation arguments to parse
/// \param [out] diags DiagnosticsEngine to report erros with
static bool parseFloatingPointArgs(CompilerInvocation &invoc,
llvm::opt::ArgList &args,
clang::DiagnosticsEngine &diags) {
LangOptions &opts = invoc.getLangOpts();
if (const llvm::opt::Arg *a =
args.getLastArg(clang::driver::options::OPT_ffp_contract)) {
const llvm::StringRef val = a->getValue();
enum LangOptions::FPModeKind fpContractMode;
if (val == "off")
fpContractMode = LangOptions::FPM_Off;
else if (val == "fast")
fpContractMode = LangOptions::FPM_Fast;
else {
diags.Report(clang::diag::err_drv_unsupported_option_argument)
<< a->getSpelling() << val;
return false;
}
opts.setFPContractMode(fpContractMode);
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_menable_no_infinities)) {
opts.NoHonorInfs = true;
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_menable_no_nans)) {
opts.NoHonorNaNs = true;
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_fapprox_func)) {
opts.ApproxFunc = true;
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_fno_signed_zeros)) {
opts.NoSignedZeros = true;
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_mreassociate)) {
opts.AssociativeMath = true;
}
2022-11-30 10:33:22 +00:00
if (args.getLastArg(clang::driver::options::OPT_freciprocal_math)) {
opts.ReciprocalMath = true;
}
if (args.getLastArg(clang::driver::options::OPT_ffast_math)) {
opts.NoHonorInfs = true;
opts.NoHonorNaNs = true;
opts.AssociativeMath = true;
opts.ReciprocalMath = true;
opts.ApproxFunc = true;
opts.NoSignedZeros = true;
opts.setFPContractMode(LangOptions::FPM_Fast);
}
return true;
}
bool CompilerInvocation::createFromArgs(
CompilerInvocation &res, llvm::ArrayRef<const char *> commandLineArgs,
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
clang::DiagnosticsEngine &diags) {
bool success = true;
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
// Set the default triple for this CompilerInvocation. This might be
// overridden by users with `-triple` (see the call to `ParseTargetArgs`
// below).
// NOTE: Like in Clang, it would be nice to use option marshalling
// for this so that the entire logic for setting-up the triple is in one
// place.
res.getTargetOpts().triple =
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple());
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// Parse the arguments
const llvm::opt::OptTable &opts = clang::driver::getDriverOptTable();
const unsigned includedFlagsBitmask = clang::driver::options::FC1Option;
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
unsigned missingArgIndex, missingArgCount;
llvm::opt::InputArgList args = opts.ParseArgs(
commandLineArgs, missingArgIndex, missingArgCount, includedFlagsBitmask);
// Check for missing argument error.
if (missingArgCount) {
diags.Report(clang::diag::err_drv_missing_argument)
<< args.getArgString(missingArgIndex) << missingArgCount;
success = false;
}
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
// Issue errors on unknown arguments
for (const auto *a : args.filtered(clang::driver::options::OPT_UNKNOWN)) {
auto argString = a->getAsString(args);
std::string nearest;
if (opts.findNearest(argString, nearest, includedFlagsBitmask) > 1)
diags.Report(clang::diag::err_drv_unknown_argument) << argString;
else
diags.Report(clang::diag::err_drv_unknown_argument_with_suggestion)
<< argString << nearest;
success = false;
}
// -flang-experimental-hlfir
if (args.hasArg(clang::driver::options::OPT_flang_experimental_hlfir)) {
res.loweringOpts.setLowerToHighLevelFIR(true);
}
success &= parseFrontendArgs(res.getFrontendOpts(), args, diags);
parseTargetArgs(res.getTargetOpts(), args);
parsePreprocessorArgs(res.getPreprocessorOpts(), args);
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
parseCodeGenArgs(res.getCodeGenOpts(), args, diags);
success &= parseSemaArgs(res, args, diags);
success &= parseDialectArgs(res, args, diags);
success &= parseDiagArgs(res, args, diags);
res.frontendOpts.llvmArgs =
args.getAllArgValues(clang::driver::options::OPT_mllvm);
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
res.frontendOpts.mlirArgs =
args.getAllArgValues(clang::driver::options::OPT_mmlir);
success &= parseFloatingPointArgs(res, args, diags);
[flang][driver] Add the new flang compiler and frontend drivers 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
2020-09-11 10:17:31 +01:00
return success;
}
void CompilerInvocation::collectMacroDefinitions() {
auto &ppOpts = this->getPreprocessorOpts();
[flang][driver] Add support for `-cpp/-nocpp` This patch adds support for the `-cpp` and `-nocpp` flags. The implemented semantics match f18 (i.e. the "throwaway" driver), but are different to gfortran. In Flang the preprocessor is always run. Instead, `-cpp/-nocpp` are used to control whether predefined and command-line preprocessor macro definitions are enabled or not. In practice this is sufficient to model gfortran`s `-cpp/-nocpp`. In the absence of `-cpp/-nocpp`, the driver will use the extension of the input file to decide whether to include the standard macro predefinitions. gfortran's documentation [1] was used to decide which file extension to use for this. The logic mentioned above was added in FrontendAction::BeginSourceFile. That's relatively late in the driver set-up, but this roughly where the name of the input file becomes available. The logic for deciding between fixed and free form works in a similar way and was also moved to FrontendAction::BeginSourceFile for consistency (and to reduce code-duplication). The `-cpp/-nocpp` flags are respected also when the input is read from stdin. This is different to: * gfortran (behaves as if `-cpp` was used) * f18 (behaves as if `-nocpp` was used) Starting with this patch, file extensions are significant and some test files had to be renamed to reflect that. Where possible, preprocessor tests were updated so that they can be shared between `f18` and `flang-new`. This was implemented on top of adding new test for `-cpp/-nocpp`. [1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D99292
2021-04-07 11:42:37 +00:00
for (unsigned i = 0, n = ppOpts.macros.size(); i != n; ++i) {
llvm::StringRef macro = ppOpts.macros[i].first;
bool isUndef = ppOpts.macros[i].second;
std::pair<llvm::StringRef, llvm::StringRef> macroPair = macro.split('=');
llvm::StringRef macroName = macroPair.first;
llvm::StringRef macroBody = macroPair.second;
// For an #undef'd macro, we only care about the name.
if (isUndef) {
parserOpts.predefinitions.emplace_back(macroName.str(),
std::optional<std::string>{});
continue;
}
// For a #define'd macro, figure out the actual definition.
if (macroName.size() == macro.size())
macroBody = "1";
else {
// Note: GCC drops anything following an end-of-line character.
llvm::StringRef::size_type end = macroBody.find_first_of("\n\r");
macroBody = macroBody.substr(0, end);
}
parserOpts.predefinitions.emplace_back(
macroName, std::optional<std::string>(macroBody.str()));
}
}
void CompilerInvocation::setDefaultFortranOpts() {
auto &fortranOptions = getFortranOpts();
std::vector<std::string> searchDirectories{"."s};
fortranOptions.searchDirectories = searchDirectories;
// Add the location of omp_lib.h to the search directories. Currently this is
// identical to the modules' directory.
fortranOptions.searchDirectories.emplace_back(getOpenMPHeadersDir());
fortranOptions.isFixedForm = false;
}
// TODO: When expanding this method, consider creating a dedicated API for
// this. Also at some point we will need to differentiate between different
// targets and add dedicated predefines for each.
void CompilerInvocation::setDefaultPredefinitions() {
auto &fortranOptions = getFortranOpts();
const auto &frontendOptions = getFrontendOpts();
// Populate the macro list with version numbers and other predefinitions.
fortranOptions.predefinitions.emplace_back("__flang__", "1");
fortranOptions.predefinitions.emplace_back("__flang_major__",
FLANG_VERSION_MAJOR_STRING);
fortranOptions.predefinitions.emplace_back("__flang_minor__",
FLANG_VERSION_MINOR_STRING);
fortranOptions.predefinitions.emplace_back("__flang_patchlevel__",
FLANG_VERSION_PATCHLEVEL_STRING);
// Add predefinitions based on extensions enabled
if (frontendOptions.features.IsEnabled(
Fortran::common::LanguageFeature::OpenACC)) {
fortranOptions.predefinitions.emplace_back("_OPENACC", "202011");
}
if (frontendOptions.features.IsEnabled(
Fortran::common::LanguageFeature::OpenMP)) {
fortranOptions.predefinitions.emplace_back("_OPENMP", "201511");
}
llvm::Triple targetTriple{llvm::Triple(this->targetOpts.triple)};
if (targetTriple.getArch() == llvm::Triple::ArchType::x86_64) {
fortranOptions.predefinitions.emplace_back("__x86_64__", "1");
fortranOptions.predefinitions.emplace_back("__x86_64", "1");
}
}
void CompilerInvocation::setFortranOpts() {
auto &fortranOptions = getFortranOpts();
const auto &frontendOptions = getFrontendOpts();
const auto &preprocessorOptions = getPreprocessorOpts();
auto &moduleDirJ = getModuleDir();
if (frontendOptions.fortranForm != FortranForm::Unknown) {
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
fortranOptions.isFixedForm =
frontendOptions.fortranForm == FortranForm::FixedForm;
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
}
fortranOptions.fixedFormColumns = frontendOptions.fixedFormColumns;
[flang][driver] Add forced form flags and -ffixed-line-length Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
2021-01-26 16:27:30 +00:00
fortranOptions.features = frontendOptions.features;
fortranOptions.encoding = frontendOptions.encoding;
// Adding search directories specified by -I
fortranOptions.searchDirectories.insert(
fortranOptions.searchDirectories.end(),
preprocessorOptions.searchDirectoriesFromDashI.begin(),
preprocessorOptions.searchDirectoriesFromDashI.end());
// Add the ordered list of -intrinsic-modules-path
fortranOptions.searchDirectories.insert(
fortranOptions.searchDirectories.end(),
preprocessorOptions.searchDirectoriesFromIntrModPath.begin(),
preprocessorOptions.searchDirectoriesFromIntrModPath.end());
// Add the default intrinsic module directory
fortranOptions.intrinsicModuleDirectories.emplace_back(getIntrinsicDir());
// Add the directory supplied through -J/-module-dir to the list of search
// directories
if (moduleDirJ != ".")
fortranOptions.searchDirectories.emplace_back(moduleDirJ);
if (frontendOptions.instrumentedParse)
fortranOptions.instrumentedParse = true;
if (frontendOptions.showColors)
fortranOptions.showColors = true;
if (frontendOptions.needProvenanceRangeToCharBlockMappings)
fortranOptions.needProvenanceRangeToCharBlockMappings = true;
if (getEnableConformanceChecks()) {
fortranOptions.features.WarnOnAllNonstandard();
}
}
void CompilerInvocation::setSemanticsOpts(
Fortran::parser::AllCookedSources &allCookedSources) {
auto &fortranOptions = getFortranOpts();
semanticsContext = std::make_unique<semantics::SemanticsContext>(
getDefaultKinds(), fortranOptions.features, allCookedSources);
semanticsContext->set_moduleDirectory(getModuleDir())
.set_searchDirectories(fortranOptions.searchDirectories)
.set_intrinsicModuleDirectories(fortranOptions.intrinsicModuleDirectories)
.set_warnOnNonstandardUsage(getEnableConformanceChecks())
.set_warningsAreErrors(getWarnAsErr())
.set_moduleFileSuffix(getModuleFileSuffix());
llvm::Triple targetTriple{llvm::Triple(this->targetOpts.triple)};
// FIXME: Handle real(3) ?
if (targetTriple.getArch() != llvm::Triple::ArchType::x86_64) {
semanticsContext->targetCharacteristics().DisableType(
Fortran::common::TypeCategory::Real, /*kind=*/10);
}
}
/// Set \p loweringOptions controlling lowering behavior based
/// on the \p optimizationLevel.
void CompilerInvocation::setLoweringOptions() {
const CodeGenOptions &codegenOpts = getCodeGenOpts();
// Lower TRANSPOSE as a runtime call under -O0.
loweringOpts.setOptimizeTranspose(codegenOpts.OptimizationLevel > 0);
const LangOptions &langOptions = getLangOpts();
Fortran::common::MathOptionsBase &mathOpts = loweringOpts.getMathOptions();
// TODO: when LangOptions are finalized, we can represent
// the math related options using Fortran::commmon::MathOptionsBase,
// so that we can just copy it into LoweringOptions.
mathOpts
.setFPContractEnabled(langOptions.getFPContractMode() ==
LangOptions::FPM_Fast)
.setNoHonorInfs(langOptions.NoHonorInfs)
.setNoHonorNaNs(langOptions.NoHonorNaNs)
.setApproxFunc(langOptions.ApproxFunc)
.setNoSignedZeros(langOptions.NoSignedZeros)
.setAssociativeMath(langOptions.AssociativeMath)
.setReciprocalMath(langOptions.ReciprocalMath);
}