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

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

670 lines
25 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
//
//===----------------------------------------------------------------------===//
#include "flang/Frontend/CompilerInvocation.h"
#include "flang/Common/Fortran-features.h"
#include "flang/Frontend/PreprocessorOptions.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"
#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/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 <memory>
[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.preprocessorOpts())) {}
[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)
//===----------------------------------------------------------------------===//
static bool parseShowColorsArgs(
const llvm::opt::ArgList &args, bool defaultColor) {
// Color diagnostics default to auto ("on" if terminal supports) in the driver
// but default to off in cc1, 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 &O = a->getOption();
if (O.matches(clang::driver::options::OPT_fcolor_diagnostics) ||
O.matches(clang::driver::options::OPT_fdiagnostics_color)) {
ShowColors = Colors_On;
} else if (O.matches(clang::driver::options::OPT_fno_color_diagnostics) ||
O.matches(clang::driver::options::OPT_fno_diagnostics_color)) {
ShowColors = Colors_Off;
} else if (O.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());
}
bool Fortran::frontend::ParseDiagnosticArgs(clang::DiagnosticOptions &opts,
llvm::opt::ArgList &args, bool defaultDiagColor) {
opts.ShowColors = parseShowColorsArgs(args, defaultDiagColor);
return true;
}
// Tweak the frontend configuration based on the frontend action
static void setUpFrontendBasedOnAction(FrontendOptions &opts) {
assert(opts.programAction_ != Fortran::frontend::InvalidAction &&
"Fortran frontend action not set!");
if (opts.programAction_ == DebugDumpParsingLog)
opts.instrumentedParse_ = true;
if (opts.programAction_ == DebugDumpProvenance ||
opts.programAction_ == Fortran::frontend::GetDefinition)
opts.needProvenanceRangeToCharBlockMappings_ = true;
}
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;
[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;
break;
case clang::driver::options::OPT_E:
opts.programAction_ = PrintPreprocessedInput;
break;
case clang::driver::options::OPT_fsyntax_only:
opts.programAction_ = ParseSyntaxOnly;
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;
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;
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_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;
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
}
[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
opts.outputFile_ = args.getLastArgValue(clang::driver::options::OPT_o);
[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
opts.showHelp_ = args.hasArg(clang::driver::options::OPT_help);
opts.showVersion_ = args.hasArg(clang::driver::options::OPT_version);
// 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();
// Principal languages.
dashX = llvm::StringSwitch<InputKind>(XValue)
.Case("f90", Language::Fortran)
.Default(Language::Unknown);
// Some special cases cannot be combined with suffixes.
if (dashX.IsUnknown())
dashX = llvm::StringSwitch<InputKind>(XValue)
.Case("ir", Language::LLVM_IR)
.Default(Language::Unknown);
if (dashX.IsUnknown())
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();
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(
llvm::StringRef(inputs[i]).rsplit('.').second);
if (ik.IsUnknown())
ik = Language::Unknown;
if (i == 0)
dashX = ik;
}
opts.inputs_.emplace_back(std::move(inputs[i]), ik);
}
[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_ =
arg->getOption().matches(clang::driver::options::OPT_ffixed_form)
? FortranForm::FixedForm
: FortranForm::FreeForm;
}
// Set fixedFormColumns_ based on -ffixed-line-length=<value>
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;
} 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;
}
}
if (const llvm::opt::Arg *arg =
args.getLastArg(clang::driver::options::OPT_fimplicit_none,
clang::driver::options::OPT_fno_implicit_none)) {
opts.features_.Enable(
Fortran::common::LanguageFeature::ImplicitNoneTypeAlways,
arg->getOption().matches(clang::driver::options::OPT_fimplicit_none));
}
if (const llvm::opt::Arg *arg =
args.getLastArg(clang::driver::options::OPT_fbackslash,
clang::driver::options::OPT_fno_backslash)) {
opts.features_.Enable(Fortran::common::LanguageFeature::BackslashEscapes,
arg->getOption().matches(clang::driver::options::OPT_fbackslash));
}
if (const llvm::opt::Arg *arg =
args.getLastArg(clang::driver::options::OPT_flogical_abbreviations,
clang::driver::options::OPT_fno_logical_abbreviations)) {
opts.features_.Enable(
Fortran::common::LanguageFeature::LogicalAbbreviations,
arg->getOption().matches(
clang::driver::options::OPT_flogical_abbreviations));
}
if (const llvm::opt::Arg *arg =
args.getLastArg(clang::driver::options::OPT_fxor_operator,
clang::driver::options::OPT_fno_xor_operator)) {
opts.features_.Enable(Fortran::common::LanguageFeature::XOROperator,
arg->getOption().matches(clang::driver::options::OPT_fxor_operator));
}
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);
}
/// 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_ =
(currentArg->getOption().matches(clang::driver::options::OPT_cpp))
? PPMacrosFlag::Include
: PPMacrosFlag::Exclude;
}
/// 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());
}
// -fno-analyzed-objects-for-unparse
if (args.hasArg(
clang::driver::options::OPT_fno_analyzed_objects_for_unparse)) {
res.SetUseAnalyzedObjectsForUnparse(false);
}
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)) {
if (args.getLastArgValue(clang::driver::options::OPT_W_Joined)
.equals("error")) {
res.SetWarnAsErr(true);
} else {
const unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"Only `-Werror` is supported currently.");
diags.Report(diagID);
}
}
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.defaultKinds().set_defaultRealKind(8);
res.defaultKinds().set_doublePrecisionKind(16);
}
if (args.hasArg(clang::driver::options::OPT_fdefault_integer_8)) {
res.defaultKinds().set_defaultIntegerKind(8);
res.defaultKinds().set_subscriptIntegerKind(8);
res.defaultKinds().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.defaultKinds().set_doublePrecisionKind(8);
}
if (args.hasArg(clang::driver::options::OPT_flarge_sizes))
res.defaultKinds().set_sizeIntegerKind(8);
// -fopenmp and -fopenacc
if (args.hasArg(clang::driver::options::OPT_fopenacc)) {
res.frontendOpts().features_.Enable(
Fortran::common::LanguageFeature::OpenACC);
}
if (args.hasArg(clang::driver::options::OPT_fopenmp)) {
res.frontendOpts().features_.Enable(
Fortran::common::LanguageFeature::OpenMP);
}
// -pedantic
if (args.hasArg(clang::driver::options::OPT_pedantic)) {
res.set_EnableConformanceChecks();
}
// -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.set_EnableConformanceChecks();
} else {
const unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"Only -std=f2018 is allowed currently.");
diags.Report(diagID);
}
}
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
bool CompilerInvocation::CreateFromArgs(CompilerInvocation &res,
llvm::ArrayRef<const char *> commandLineArgs,
clang::DiagnosticsEngine &diags) {
bool success = true;
// 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;
}
success &= ParseFrontendArgs(res.frontendOpts(), args, diags);
parsePreprocessorArgs(res.preprocessorOpts(), args);
success &= parseSemaArgs(res, args, diags);
success &= parseDialectArgs(res, args, diags);
success &= parseDiagArgs(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;
}
[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
void CompilerInvocation::collectMacroDefinitions() {
auto &ppOpts = this->preprocessorOpts();
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) {
[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
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);
}
[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
parserOpts_.predefinitions.emplace_back(
macroName, std::optional<std::string>(macroBody.str()));
}
}
void CompilerInvocation::SetDefaultFortranOpts() {
auto &fortranOptions = fortranOpts();
// These defaults are based on the defaults in f18/f18.cpp.
std::vector<std::string> searchDirectories{"."s};
fortranOptions.searchDirectories = searchDirectories;
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 = fortranOpts();
const auto &frontendOptions = frontendOpts();
// 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");
}
}
void CompilerInvocation::setFortranOpts() {
auto &fortranOptions = fortranOpts();
[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
const auto &frontendOptions = frontendOpts();
const auto &preprocessorOptions = preprocessorOpts();
auto &moduleDirJ = moduleDir();
[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 (frontendOptions.fortranForm_ != FortranForm::Unknown) {
fortranOptions.isFixedForm =
frontendOptions.fortranForm_ == FortranForm::FixedForm;
}
fortranOptions.fixedFormColumns = frontendOptions.fixedFormColumns_;
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 at the end
fortranOptions.searchDirectories.emplace_back(getIntrinsicDir());
// Add the directory supplied through -J/-module-dir to the list of search
// directories
if (moduleDirJ.compare(".") != 0)
fortranOptions.searchDirectories.emplace_back(moduleDirJ);
if (frontendOptions.instrumentedParse_)
fortranOptions.instrumentedParse = true;
if (frontendOptions.needProvenanceRangeToCharBlockMappings_)
fortranOptions.needProvenanceRangeToCharBlockMappings = true;
if (enableConformanceChecks()) {
fortranOptions.features.WarnOnAllNonstandard();
}
}
void CompilerInvocation::setSemanticsOpts(
Fortran::parser::AllCookedSources &allCookedSources) {
const auto &fortranOptions = fortranOpts();
semanticsContext_ = std::make_unique<semantics::SemanticsContext>(
defaultKinds(), fortranOptions.features, allCookedSources);
semanticsContext_->set_moduleDirectory(moduleDir())
.set_searchDirectories(fortranOptions.searchDirectories)
.set_warnOnNonstandardUsage(enableConformanceChecks())
.set_warningsAreErrors(warnAsErr())
.set_moduleFileSuffix(moduleFileSuffix());
}