maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/flang/test/Driver/driver-help.f90

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

151 lines
10 KiB
Fortran
Raw Normal View History

[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 19:33:19 +08:00
!--------------------------
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! FLANG DRIVER (flang)
[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 19:33:19 +08:00
!--------------------------
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! RUN: %flang -help 2>&1 | FileCheck %s --check-prefix=HELP
! RUN: not %flang -helps 2>&1 | FileCheck %s --check-prefix=ERROR
[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 17:17:31 +08: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 19:33:19 +08:00
!----------------------------------------
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! FLANG FRONTEND DRIVER (flang -fc1)
[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 19:33:19 +08:00
!----------------------------------------
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! RUN: %flang_fc1 -help 2>&1 | FileCheck %s --check-prefix=HELP-FC1
! RUN: not %flang_fc1 -helps 2>&1 | FileCheck %s --check-prefix=ERROR
[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 17:17:31 +08:00
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! HELP:USAGE: flang
[flang] Introduce DiagnosticConsumer classes in libflangFrontend Currently Flang uses TextDiagnostic, TextDiagnosticPrinter & TestDiagnosticBuffer classes from Clang (more specifically, from libclangFrontend). This patch introduces simplified equivalents of these classes in Flang (i.e. it removes the dependency on libclangFrontend). Flang only needs these diagnostics classes for the compiler driver diagnostics. This is unlike in Clang in which similar diagnostic classes are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the implementations introduced here are relatively basic. We can extend them in the future if this is required. This patch also enhances how the diagnostics are printed. In particular, this is the diagnostic that you'd get _before_ the changes introduced here (no text formatting): ``` $ bin/flang-new error: no input files ``` This is the diagnostic that you get _after_ the changes introduced here (in terminals that support it, the text is formatted - bold + red): ``` $ bin/flang-new flang-new: error: no input files ``` Tests are updated accordingly and options related to enabling/disabling color diagnostics are flagged as supported by Flang. Reviewed By: sameeranjoshi, CarolineConcatto Differential Revision: https://reviews.llvm.org/D87774
2020-10-06 00:42:00 +08:00
! HELP-EMPTY:
! HELP-NEXT:OPTIONS:
[flang][driver] Make sure that `-###` is marked as supported (NFC) `-###` has always been supported in the new flang driver. This patch merely makes sure that it's included when printing the help screen (i.e. `flang-new -help`).
2020-11-11 16:45:54 +08:00
! HELP-NEXT: -### Print (but do not run) the commands to run for this compilation
[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 19:42:37 +08:00
! HELP-NEXT: -cpp Enable predefined and command line preprocessor macros
[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 17:08:54 +08:00
! HELP-NEXT: -c Only run preprocess, compile, and assemble steps
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-NEXT: -D <macro>=<value> Define <macro> to <value> (or 1 if <value> omitted)
[flang][driver] Add support for `--target`/`--triple` This patch adds support for: * `--target` in the compiler driver (`flang-new`) * `--triple` in the frontend driver (`flang-new -fc1`) The semantics of these flags are inherited from `clangDriver`, i.e. consistent with `clang --target` and `clang -cc1 --triple`, respectively. A new structure is defined, `TargetOptions`, that will hold various Frontend options related to the target. Currently, this is mostly a placeholder that contains the target triple. In the future, it will be used for storing e.g. the CPU to tune for or the target features to enable. Additionally, the following target/triple related options are enabled [*]: `-print-effective-triple`, `-print-target-triple`. Definitions in Options.td are updated accordingly and, to facilated testing, `-emit-llvm` is added to the list of options available in `flang-new` (previously it was only enabled in `flang-new -fc1`). [*] These options were actually available before (like all other options defined in `clangDriver`), but not included in `flang-new --help`. Before this change, `flang-new` would just use `native` for defining the target, so these options were of little value. Differential Revision: https://reviews.llvm.org/D120246
2022-02-21 19:51:32 +08:00
! HELP-NEXT: -emit-llvm Use the LLVM representation for assembler and object files
[Flang][Driver] Add PrintPreprocessedInput FrontendAction (`flang-new -E`) This patch implements the first frontend action for the Flang parser (i.e. Fortran::parser). This action runs the preprocessor and is invoked with the `-E` flag. (i.e. `flang-new -E <input-file>). The generated output is printed to either stdout or the output file (specified with `-` or `-o <output-file>`). Note that currently there is no mechanism to map options for the frontend driver (i.e. Fortran::frontend::FrontendOptions) to options for the parser (i.e. Fortran::parser::Options). Instead, Frotran::parser::options are hard-coded to: ``` std::vector<std::string> searchDirectories{"."s}; searchDirectories = searchDirectories; isFixedForm = false; _encoding(Fortran::parser::Encoding::UTF_8); ``` These default settings are compatible with the current Flang driver. Further work is required in order for CompilerInvocation to read and map clang::driver::options to Fortran::parser::options. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D88381
2020-10-27 20:26:47 +08:00
! HELP-NEXT: -E Only run the preprocessor
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-NEXT: -falternative-parameter-statement
! HELP-NEXT: Enable the old style PARAMETER statement
! HELP-NEXT: -fbackslash Specify that backslash in string introduces an escape character
[flang] Introduce DiagnosticConsumer classes in libflangFrontend Currently Flang uses TextDiagnostic, TextDiagnosticPrinter & TestDiagnosticBuffer classes from Clang (more specifically, from libclangFrontend). This patch introduces simplified equivalents of these classes in Flang (i.e. it removes the dependency on libclangFrontend). Flang only needs these diagnostics classes for the compiler driver diagnostics. This is unlike in Clang in which similar diagnostic classes are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the implementations introduced here are relatively basic. We can extend them in the future if this is required. This patch also enhances how the diagnostics are printed. In particular, this is the diagnostic that you'd get _before_ the changes introduced here (no text formatting): ``` $ bin/flang-new error: no input files ``` This is the diagnostic that you get _after_ the changes introduced here (in terminals that support it, the text is formatted - bold + red): ``` $ bin/flang-new flang-new: error: no input files ``` Tests are updated accordingly and options related to enabling/disabling color diagnostics are flagged as supported by Flang. Reviewed By: sameeranjoshi, CarolineConcatto Differential Revision: https://reviews.llvm.org/D87774
2020-10-06 00:42:00 +08:00
! HELP-NEXT: -fcolor-diagnostics Enable colors in diagnostics
[flang][driver] Add options for -fdefault* and -flarge-sizes Add support for the following Fortran dialect options: - -default* - -flarge-sizes It also adds two test cases: # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`. # For checking if `fdefault-` arguments are processed properly. Also moves the Dialect related option parsing to a dedicated function and adds a member `defaultKinds()` to `CompilerInvocation` Depends on: D96032 Differential Revision: https://reviews.llvm.org/D96344
2021-03-04 00:28:11 +08:00
! HELP-NEXT: -fdefault-double-8 Set the default double precision kind to an 8 byte wide type
! HELP-NEXT: -fdefault-integer-8 Set the default integer kind to an 8 byte wide type
! HELP-NEXT: -fdefault-real-8 Set the default real kind to an 8 byte wide type
[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-27 00:27:30 +08:00
! HELP-NEXT: -ffixed-form Process source files in fixed form
! HELP-NEXT: -ffixed-line-length=<value>
! HELP-NEXT: Use <value> as character line width in fixed mode
! HELP-NEXT: -ffree-form Process source files in free form
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-NEXT: -fimplicit-none No implicit typing allowed unless overridden by IMPLICIT statements
! HELP-NEXT: -finput-charset=<value> Specify the default character set for source files
[flang][driver] Add -fintrinsic-modules-path option Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97080
2021-03-24 00:24:57 +08:00
! HELP-NEXT: -fintrinsic-modules-path <dir>
! HELP-NEXT: Specify where to find the compiled intrinsic modules
[flang][driver] Add options for -fdefault* and -flarge-sizes Add support for the following Fortran dialect options: - -default* - -flarge-sizes It also adds two test cases: # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`. # For checking if `fdefault-` arguments are processed properly. Also moves the Dialect related option parsing to a dedicated function and adds a member `defaultKinds()` to `CompilerInvocation` Depends on: D96032 Differential Revision: https://reviews.llvm.org/D96344
2021-03-04 00:28:11 +08:00
! HELP-NEXT: -flarge-sizes Use INTEGER(KIND=8) for the result type in size-related intrinsics
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-NEXT: -flogical-abbreviations Enable logical abbreviations
[flang] Add -fno-automatic, refine IsSaved() This legacy option (available in other Fortran compilers with various spellings) implies the SAVE attribute for local variables on subprograms that are not explicitly RECURSIVE. The SAVE attribute essentially implies static rather than stack storage. This was the default setting in Fortran until surprisingly recently, so explicit SAVE statements & attributes could be and often were omitted from older codes. Note that initialized objects already have an implied SAVE attribute, and objects in COMMON effectively do too, as data overlays are extinct; and since objects that are expected to survive from one invocation of a procedure to the next in static storage should probably be explicit initialized in the first place, so the use cases for this option are somewhat rare, and all of them could be handled with explicit SAVE statements or attributes. This implicit SAVE attribute must not apply to automatic (in the Fortran sense) local objects, whose sizes cannot be known at compilation time. To get the semantics of IsSaved() right, the IsAutomatic() predicate was moved into Evaluate/tools.cpp to allow for dynamic linking of the compiler. The redundant predicate IsAutomatic() was noticed, removed, and its uses replaced. GNU Fortran's spelling of the option (-fno-automatic) was added to the clang-based driver and used for basic sanity testing. Differential Revision: https://reviews.llvm.org/D114209
2021-11-19 03:48:42 +08:00
! HELP-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
[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 18:57:48 +08:00
! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
[flang][driver] Add support for -save-temps This patch adds support for `-save-temps` in `flang-new`, Flang's compiler driver. The semantics of this option are inherited from Clang. The file extension for temporary Fortran preprocessed files is set to `i`. This is identical to what Clang uses for C (or C++) preprocessed files. I have tried researching what other compilers do here, but I couldn't find any definitive answers. One GFortran thread [1] suggests that indeed it is not clear what the right approach should be. Normally, various phases in Clang/Flang are combined. The `-save-temps` option works by forcing the compiler to run every phase separately. As there is no integrated assembler driver in Flang, user will have to use `-save-temps` together with `-fno-integrated-as`. Otherwise, an invocation to the integrated assembler would be generated generated, which is going to fail (i.e. something equivalent to `clang -cc1as` from Clang). There are no specific plans for implementing an integrated assembler for Flang for now. One possible solution would be to share it entirely with Clang. Note that on Windows you will get the following error when using `-fno-integrated-as`: ```bash flang-new: error: there is no external assembler that can be used on this platform ``` Unfortunately, I don't have access to a Windows machine to investigate this. Instead, I marked the tests in this patch as unsupported on Windows. [1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615 Differential Revision: https://reviews.llvm.org/D124669
2022-04-29 19:48:36 +08:00
! HELP-NEXT: -fno-integrated-as Disable the integrated assembler
[flang][driver] Add support for -fopenmp and -fopenacc Add support for the following options: * -fopenmp * -fopenacc Update OpenMP and OpenACC semantics tests to use the new driver if it is built, otherwise use f18. OpenMP tests that include `use omp_lib` or run `test_symbols.sh` have not been updated as they require options `-intrinsic-module-directory` and `-funparse-with-symbols` which are currently not implemented in the new driver. Similarly OpenACC tests that run `test_symbols.sh` have not been updated. This patch also moves semanticsContext to CompilerInvocation and creates it in CompilerInvocation#setSemanticsOpts so that the semantics context can use Fortran::parser::Options#features. Summary of changes: - Move semanticsContext to CompilerInvocation.h - Update OpenMP and OpenACC semantics tests that do not rely on `-intrinsic-module-directory` and `-funparse-with-symbols` to use %flang Differential Revision: https://reviews.llvm.org/D96032
2021-02-10 17:24:45 +08:00
! HELP-NEXT: -fopenacc Enable OpenACC
! HELP-NEXT: -fopenmp Parse OpenMP pragmas and generate parallel code.
[clang,flang] Add help text for -fsyntax-only Fix for the problem with displaying options `-fsyntax-only` in clang and flang-new in help Fix https://github.com/llvm/llvm-project/issues/57033 Before: ``` $ clang -help | grep syntax -objcmt-migrate-property-dot-syntax Enable migration of setter/getter messages to property-dot syntax ``` After: ``` $ clang -help | grep syntax -fsyntax-only Run the preprocessor, parser and semantic analysis stages -objcmt-migrate-property-dot-syntax Enable migration of setter/getter messages to property-dot syntax ``` Reviewed By: vzakhari, awarzynski, MaskRay, alexiprof Differential Revision: https://reviews.llvm.org/D131808
2022-08-19 17:53:27 +08:00
! HELP-NEXT: -fsyntax-only Run the preprocessor, parser and semantic analysis stages
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-NEXT: -fxor-operator Enable .XOR. as a synonym of .NEQV.
[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 19:33:19 +08:00
! HELP-NEXT: -help Display available options
[flang][driver] Add support for `-I` in the new driver Add support for option -I in the new Flang driver. This will allow for included headers and module files in other directories, as the default search path is currently the working folder. The behaviour of this is consistent with the current f18 driver, where the current folder (i.e. ".") has the highest priority followed by the order of '-I's taking priority from first to last. Summary of changes: - Add SearchDirectoriesFromDashI to PreprocessorOptions, to be forwarded into the parser's searchDirectories - Add header files and non-functional module files to be used in regression tests. The module files are just text files and are used to demonstrated that paths specified with `-I` are taken into account when searching for .mod files. Differential Revision: https://reviews.llvm.org/D93453
2021-01-19 18:01:38 +08:00
! HELP-NEXT: -I <dir> Add directory to the end of the list of include search paths
[flang][driver] Add support for `-mllvm` This option is added in both `flang-new` (the compiler driver) and `flang-new -fc1` (the frontend driver). The semantics are consistent with `clang` and `clang -cc1`. As Flang does not run any LLVM passes when invoked with `-emit-llvm` (i.e. `flang-new -S -emit-llvm <file>`), the tests use `-S`/`-c`/`-emit-obj` instead. These options require an LLVM backend to be run by the driver to generate the output (this makese `-mllvm` relevant here). Differential Revision: https://reviews.llvm.org/D121374
2022-03-02 23:40:16 +08:00
! HELP-NEXT: -mllvm <value> Additional arguments to forward to LLVM's option processing
[flang][driver] Add support for `-mmlir` The semantics of `-mmlir` are identical to `-mllvm`. The only notable difference is that `-mmlir` options should be forwarded to MLIR rather than LLVM. Note that MLIR llvm::cl options are lazily constructed on demand (see the definition of options in PassManagerOptions.cpp). This means that: * MLIR global options are only visible when explicitly initialised and displayed only when using `-mmlir --help`, * Flang and LLVM global options are always visible and displayed when using either `-mllvm -help` or `-mmlir --help`. In other words, `-mmlir --help` is a superset of `-mllvm --help`. This is not ideal, but we'd need to refactor all option definitions in Flang and LLVM to improve this. I suggesting leaving this for later. Differential Revision: https://reviews.llvm.org/D123297
2022-04-07 17:47:23 +08:00
! HELP-NEXT: -mmlir <value> Additional arguments to forward to MLIR's option processing
[flang][driver] Add support for `-J/-module-dir` Add support for option -J/-module-dir in the new Flang driver. This will allow for including module files in other directories, as the default search path is currently the working folder. This also provides an option of storing the output module in the specified folder. Differential Revision: https://reviews.llvm.org/D95448
2021-02-05 00:13:04 +08:00
! HELP-NEXT: -module-dir <dir> Put MODULE files in <dir>
[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 19:42:37 +08:00
! HELP-NEXT: -nocpp Disable predefined and command line preprocessor macros
[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 19:33:19 +08:00
! HELP-NEXT: -o <file> Write output to <file>
[flang][driver] Add options for -std=f2018 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97119
2021-03-26 01:02:05 +08:00
! HELP-NEXT: -pedantic Warn on language extensions
[flang][driver] Add support for `--target`/`--triple` This patch adds support for: * `--target` in the compiler driver (`flang-new`) * `--triple` in the frontend driver (`flang-new -fc1`) The semantics of these flags are inherited from `clangDriver`, i.e. consistent with `clang --target` and `clang -cc1 --triple`, respectively. A new structure is defined, `TargetOptions`, that will hold various Frontend options related to the target. Currently, this is mostly a placeholder that contains the target triple. In the future, it will be used for storing e.g. the CPU to tune for or the target features to enable. Additionally, the following target/triple related options are enabled [*]: `-print-effective-triple`, `-print-target-triple`. Definitions in Options.td are updated accordingly and, to facilated testing, `-emit-llvm` is added to the list of options available in `flang-new` (previously it was only enabled in `flang-new -fc1`). [*] These options were actually available before (like all other options defined in `clangDriver`), but not included in `flang-new --help`. Before this change, `flang-new` would just use `native` for defining the target, so these options were of little value. Differential Revision: https://reviews.llvm.org/D120246
2022-02-21 19:51:32 +08:00
! HELP-NEXT: -print-effective-triple Print the effective target triple
! HELP-NEXT: -print-target-triple Print the normalized target triple
[flang] Produce proper "preprocessor output" for -E option Rename the current -E option to "-E -Xflang -fno-reformat". Add a new Parsing::EmitPreprocessedSource() routine to convert the cooked character stream output of the prescanner back to something more closely resembling output from a traditional preprocessor; call this new routine when -E appears. The new -E output is suitable for use as fixed form Fortran source to compilation by (one hopes) any Fortran compiler. If the original top-level source file had been free form source, the output will be suitable for use as free form source as well; otherwise there may be diagnostics about missing spaces if they were indeed absent in the original fixed form source. Unless the -P option appears, #line directives are interspersed with the output (but be advised, f18 will ignore these if presented with them in a later compilation). An effort has been made to preserve original alphabetic character case and source indentation. Add -P and -fno-reformat to the new drivers. Tweak test options to avoid confusion with prior -E output; use -fno-reformat where needed, but prefer to keep -E, sometimes in concert with -P, on most, updating expected results accordingly. Differential Revision: https://reviews.llvm.org/D106727
2021-07-24 07:41:04 +08:00
! HELP-NEXT: -P Disable linemarker output in -E mode
[flang][driver] Add support for -save-temps This patch adds support for `-save-temps` in `flang-new`, Flang's compiler driver. The semantics of this option are inherited from Clang. The file extension for temporary Fortran preprocessed files is set to `i`. This is identical to what Clang uses for C (or C++) preprocessed files. I have tried researching what other compilers do here, but I couldn't find any definitive answers. One GFortran thread [1] suggests that indeed it is not clear what the right approach should be. Normally, various phases in Clang/Flang are combined. The `-save-temps` option works by forcing the compiler to run every phase separately. As there is no integrated assembler driver in Flang, user will have to use `-save-temps` together with `-fno-integrated-as`. Otherwise, an invocation to the integrated assembler would be generated generated, which is going to fail (i.e. something equivalent to `clang -cc1as` from Clang). There are no specific plans for implementing an integrated assembler for Flang for now. One possible solution would be to share it entirely with Clang. Note that on Windows you will get the following error when using `-fno-integrated-as`: ```bash flang-new: error: there is no external assembler that can be used on this platform ``` Unfortunately, I don't have access to a Windows machine to investigate this. Instead, I marked the tests in this patch as unsupported on Windows. [1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615 Differential Revision: https://reviews.llvm.org/D124669
2022-04-29 19:48:36 +08:00
! HELP-NEXT: -save-temps=<value> Save intermediate compilation results.
! HELP-NEXT: -save-temps Save intermediate compilation results
[flang][driver] Add options for -std=f2018 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97119
2021-03-26 01:02:05 +08:00
! HELP-NEXT: -std=<value> Language standard to compile for
[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-25 01:34:27 +08:00
! HELP-NEXT: -S Only run preprocess and compilation steps
[flang][driver] Add support for `--target`/`--triple` This patch adds support for: * `--target` in the compiler driver (`flang-new`) * `--triple` in the frontend driver (`flang-new -fc1`) The semantics of these flags are inherited from `clangDriver`, i.e. consistent with `clang --target` and `clang -cc1 --triple`, respectively. A new structure is defined, `TargetOptions`, that will hold various Frontend options related to the target. Currently, this is mostly a placeholder that contains the target triple. In the future, it will be used for storing e.g. the CPU to tune for or the target features to enable. Additionally, the following target/triple related options are enabled [*]: `-print-effective-triple`, `-print-target-triple`. Definitions in Options.td are updated accordingly and, to facilated testing, `-emit-llvm` is added to the list of options available in `flang-new` (previously it was only enabled in `flang-new -fc1`). [*] These options were actually available before (like all other options defined in `clangDriver`), but not included in `flang-new --help`. Before this change, `flang-new` would just use `native` for defining the target, so these options were of little value. Differential Revision: https://reviews.llvm.org/D120246
2022-02-21 19:51:32 +08:00
! HELP-NEXT: --target=<value> Generate code for the given target
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-NEXT: -U <macro> Undefine macro <macro>
[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 19:33:19 +08:00
! HELP-NEXT: --version Print version information
[flang][driver] Add options for -Werror With the option given, warnings are treated as error. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D98657
2021-04-06 00:41:46 +08:00
! HELP-NEXT: -W<warning> Enable the specified warning
[flang][driver] Add -Xflang and make -test-io a frontend-only flang This patch adds support for `-Xflang` in `flang-new`. The semantics are identical to `-Xclang`. With the addition of `-Xflang`, we can modify `-test-io` to be a compiler-frontend only flag. This makes more sense, this flag is: * very frontend specific * to be used for development and testing only * not to be exposed to the end user Originally we added it to the compiler driver, `flang-new`, in order to facilitate testing. With `-Xflang` this is no longer needed. Tests are updated accordingly. Differential Revision: https://reviews.llvm.org/D96864
2021-02-17 22:13:29 +08:00
! HELP-NEXT: -Xflang <arg> Pass <arg> to the flang compiler
[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 17:17:31 +08:00
[flang][driver] Remove `%flang-new` from the LIT configuration `%flang-new` was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced `%flang` (compiler driver) and `%flang_fc1` (frontend driver) as the long term solution. This has allowed us to share tests between `flang-new` and `f18`. This patch replaces all uses of `%flang-new` with `%flang` and `%flang_fc1`. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so that more tests can be shared with `f18`. To facilitate this, `f{no-}implicit-none` are introduced in `f18` with semantics identical to `flang-new`. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174
2021-04-09 18:32:31 +08:00
! HELP-FC1:USAGE: flang
[flang] Introduce DiagnosticConsumer classes in libflangFrontend Currently Flang uses TextDiagnostic, TextDiagnosticPrinter & TestDiagnosticBuffer classes from Clang (more specifically, from libclangFrontend). This patch introduces simplified equivalents of these classes in Flang (i.e. it removes the dependency on libclangFrontend). Flang only needs these diagnostics classes for the compiler driver diagnostics. This is unlike in Clang in which similar diagnostic classes are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the implementations introduced here are relatively basic. We can extend them in the future if this is required. This patch also enhances how the diagnostics are printed. In particular, this is the diagnostic that you'd get _before_ the changes introduced here (no text formatting): ``` $ bin/flang-new error: no input files ``` This is the diagnostic that you get _after_ the changes introduced here (in terminals that support it, the text is formatted - bold + red): ``` $ bin/flang-new flang-new: error: no input files ``` Tests are updated accordingly and options related to enabling/disabling color diagnostics are flagged as supported by Flang. Reviewed By: sameeranjoshi, CarolineConcatto Differential Revision: https://reviews.llvm.org/D87774
2020-10-06 00:42:00 +08:00
! HELP-FC1-EMPTY:
! HELP-FC1-NEXT:OPTIONS:
[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 19:42:37 +08:00
! HELP-FC1-NEXT: -cpp Enable predefined and command line preprocessor macros
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-FC1-NEXT: -D <macro>=<value> Define <macro> to <value> (or 1 if <value> omitted)
[flang][driver] Add support for generating LLVM bytecode files Support for generating LLVM BC files is added in Flang's compiler and frontend drivers. This requires the `BitcodeWriterPass` pass to be run on the input LLVM IR module and is implemented as a dedicated frontend aciton. The new functionality as seen by the user (compiler driver): ``` flang-new -c -emit-llvm file.90 ``` or (frontend driver): ``` flang-new -fc1 -emit-llvm-bc file.f90 ``` The new behaviour is consistent with `clang` and `clang -cc1`. Differential Revision: https://reviews.llvm.org/D123211
2022-04-06 19:59:28 +08:00
! HELP-FC1-NEXT: -emit-llvm-bc Build ASTs then convert to LLVM, emit .bc file
[flang][driver] Add support for `-emit-llvm` This patch adds support for the `-emit-llvm` option in the frontend driver (i.e. `flang-new -fc1`). Similarly to Clang, `flang-new -fc1 -emit-llvm file.f` will generate a textual LLVM IR file. Depends on D118985 Differential Revision: https://reviews.llvm.org/D119012
2022-02-05 01:15:12 +08:00
! HELP-FC1-NEXT: -emit-llvm Use the LLVM representation for assembler and object files
[flang][driver] Add support for `-emit-mlir` This patch adds support for generating MLIR files in Flang's frontend driver (i.e. `flang-new -fc1`). `-emit-fir` is added as an alias for `-emit-mlir`. We may want to decide to split the two in the future. A new parent class for code-gen frontend actions is introduced: `CodeGenAction`. We will be using this class to encapsulate logic shared between all code-generation actions, but not required otherwise. For now, it will: * run prescanning, parsing and semantic checks, * lower the input to MLIR. `EmitObjAction` is updated to inherit from this class. This means that the behaviour of `flang-new -fc1 -emit-obj` is also updated (previously, it would just exit immediately). This change required `flang/test/Driver/syntax-only.f90` to be updated. For `-emit-fir`, a specialisation of `CodeGenAction` is introduced: `EmitMLIRAction`. The key logic for this class is implemented in `EmitMLIRAction::ExecuteAction`. Differential Revision: https://reviews.llvm.org/D118985
2022-02-04 01:00:27 +08:00
! HELP-FC1-NEXT: -emit-mlir Build the parse tree, then lower it to MLIR
[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 17:08:54 +08:00
! HELP-FC1-NEXT: -emit-obj Emit native object files
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-FC1-NEXT: -E Only run the preprocessor
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-FC1-NEXT: -falternative-parameter-statement
! HELP-FC1-NEXT: Enable the old style PARAMETER statement
! HELP-FC1-NEXT: -fbackslash Specify that backslash in string introduces an escape character
[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
! HELP-FC1-NEXT: -fcolor-diagnostics Enable colors in diagnostics
[flang][driver] Add `-fdebug-dump-all` The new option will run the semantic checks and then dump the parse tree and all the symbols. This is equivalent to running the driver twice, once with `-fdebug-dump-parse-tree` and then with the `-fdebug-dump-symbols` action flag. Currently we wouldn't be able to achieve the same by simply running: ``` flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file> ``` That's because the new driver will only run one frontend action per invocation (both of the flags used here are action flags). Diverging from this design would lead to costly compromises and it's best avoided. We may want to consider re-designing our debugging actions (and action options) in the future so that there's more code re-use. For now, I'm focusing on making sure that we support all the major cases requested by our users. Differential Revision: https://reviews.llvm.org/D104305
2021-06-15 23:30:23 +08:00
! HELP-FC1-NEXT: -fdebug-dump-all Dump symbols and the parse tree after the semantic checks
[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 18:35:42 +08:00
! HELP-FC1-NEXT: -fdebug-dump-parse-tree-no-sema
! HELP-FC1-NEXT: Dump the parse tree (skips the semantic checks)
[flang][driver] Add debug dump options Add the following options: * -fdebug-dump-symbols * -fdebug-dump-parse-tree * -fdebug-dump-provenance Summary of changes: - Add 3 new frontend actions: DebugDumpSymbolsAction, DebugDumpParseTreeAction and DebugDumpProvenanceAction - Add a unique pointer to the Semantics instance created in PrescanAndSemaAction - Move fatal semantic error reporting to its own method, FrontendActions#reportFatalSemanticErrors - Port most tests using `-fdebug-dump-symbols` and `-fdebug-dump-parse-tree` to the new driver if built, otherwise default to f18 Differential Revision: https://reviews.llvm.org/D96716
2021-02-17 23:55:56 +08:00
! HELP-FC1-NEXT: -fdebug-dump-parse-tree Dump the parse tree
[flang][driver] Add `-fdebug-dump-parsing-log` This patch adds `-fdebug-dump-parsing-log` in the new driver. This option is semantically identical to `-fdebug-instrumented-parse` in `f18` (the former is added as an alias in `f18`). As dumping the parsing log makes only sense for instrumented parses, we set Fortran::parser::Options::instrumentedParse to `True` when `-fdebug-dump-parsing-log` is used. This is consistent with `f18`. To facilitate tweaking the configuration of the frontend based on the action being requested, `setUpFrontendBasedOnAction` is introduced in CompilerInvocation.cpp. Differential Revision: https://reviews.llvm.org/D97457
2021-02-24 01:59:17 +08:00
! HELP-FC1-NEXT: -fdebug-dump-parsing-log
! HELP-FC1-NEXT: Run instrumented parse and dump the parsing log
[flang][driver] Add support for `-debug-dump-pft` This patch adds support for dumping the pre-FIR tree in `flang-new -fc1`, i.e. Flang's frontend driver. This flag is functionally identical to `-pft-test` in `bbc` and semantically similar to `-fdebug-dump-parse-tree` from `flang-new -fc1`. Differential Revision: https://reviews.llvm.org/D121198
2022-03-08 18:01:55 +08:00
! HELP-FC1-NEXT: -fdebug-dump-pft Dump the pre-fir parse tree
[flang][driver] Add debug dump options Add the following options: * -fdebug-dump-symbols * -fdebug-dump-parse-tree * -fdebug-dump-provenance Summary of changes: - Add 3 new frontend actions: DebugDumpSymbolsAction, DebugDumpParseTreeAction and DebugDumpProvenanceAction - Add a unique pointer to the Semantics instance created in PrescanAndSemaAction - Move fatal semantic error reporting to its own method, FrontendActions#reportFatalSemanticErrors - Port most tests using `-fdebug-dump-symbols` and `-fdebug-dump-parse-tree` to the new driver if built, otherwise default to f18 Differential Revision: https://reviews.llvm.org/D96716
2021-02-17 23:55:56 +08:00
! HELP-FC1-NEXT: -fdebug-dump-provenance Dump provenance
! HELP-FC1-NEXT: -fdebug-dump-symbols Dump symbols after the semantic analysis
[flang][driver] Add debug measure-parse-tree and pre-fir-tree options Add the following options: * -fdebug-measure-parse-tree * -fdebug-pre-fir-tree Summary of changes: - Add 2 new frontend actions: DebugMeasureParseTreeAction and DebugPreFIRTreeAction - Add MeasurementVisitor to FrontendActions.h - Make reportFatalSemanticErrors return true if there are any fatal errors - Port most of the `-fdebug-pre-fir-tree` tests to use the new driver if built, otherwise use f18. Differential Revision: https://reviews.llvm.org/D96884
2021-02-18 02:53:05 +08:00
! HELP-FC1-NEXT: -fdebug-measure-parse-tree
! HELP-FC1-NEXT: Measure the parse tree
[flang][driver] Add -fdebug-module-writer option
2021-03-11 20:35:45 +08:00
! HELP-FC1-NEXT: -fdebug-module-writer Enable debug messages while writing module files
[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 17:44:21 +08:00
! HELP-FC1-NEXT: -fdebug-pass-manager Prints debug information for the new pass manage
[flang][driver] Add debug measure-parse-tree and pre-fir-tree options Add the following options: * -fdebug-measure-parse-tree * -fdebug-pre-fir-tree Summary of changes: - Add 2 new frontend actions: DebugMeasureParseTreeAction and DebugPreFIRTreeAction - Add MeasurementVisitor to FrontendActions.h - Make reportFatalSemanticErrors return true if there are any fatal errors - Port most of the `-fdebug-pre-fir-tree` tests to use the new driver if built, otherwise use f18. Differential Revision: https://reviews.llvm.org/D96884
2021-02-18 02:53:05 +08:00
! HELP-FC1-NEXT: -fdebug-pre-fir-tree Dump the pre-FIR tree
[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 18:35:42 +08:00
! HELP-FC1-NEXT: -fdebug-unparse-no-sema Unparse and stop (skips the semantic checks)
[flang][driver] Add options for unparsing This patch adds the following compiler frontend driver options: * -fdebug-unparse (f18 spelling: -funparse) * -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols) The new driver will only accept the new spelling. `f18` will accept both the original and the new spelling. A new base class for frontend actions is added: `PrescanAndSemaAction`. This is added to reduce code duplication that otherwise these new options would lead to. Implementation from * `ParseSyntaxOnlyAction::ExecutionAction` is moved to: * `PrescanAndSemaAction::BeginSourceFileAction` This implementation is now shared between: * PrescanAndSemaAction * ParseSyntaxOnlyAction * DebugUnparseAction * DebugUnparseWithSymbolsAction All tests that don't require other yet unimplemented options are updated. This way `flang-new -fc1` is used instead of `f18` when `FLANG_BUILD_NEW_DRIVER` is set to `On`. In order to facilitate this, `%flang_fc1` is added in the LIT configuration (lit.cfg.py). `asFortran` from f18.cpp is duplicated as `getBasicAsFortran` in FrontendOptions.cpp. At this stage it's hard to find a good place to share this method. I suggest that we revisit this once a switch from `f18` to `flang-new` is complete. Differential Revision: https://reviews.llvm.org/D96483
2021-02-04 19:14:57 +08:00
! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
! HELP-FC1-NEXT: Unparse and stop.
! HELP-FC1-NEXT: -fdebug-unparse Unparse and stop.
[flang][driver] Add options for -fdefault* and -flarge-sizes Add support for the following Fortran dialect options: - -default* - -flarge-sizes It also adds two test cases: # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`. # For checking if `fdefault-` arguments are processed properly. Also moves the Dialect related option parsing to a dedicated function and adds a member `defaultKinds()` to `CompilerInvocation` Depends on: D96032 Differential Revision: https://reviews.llvm.org/D96344
2021-03-04 00:28:11 +08:00
! HELP-FC1-NEXT: -fdefault-double-8 Set the default double precision kind to an 8 byte wide type
! HELP-FC1-NEXT: -fdefault-integer-8 Set the default integer kind to an 8 byte wide type
! HELP-FC1-NEXT: -fdefault-real-8 Set the default real kind to an 8 byte wide type
[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-27 00:27:30 +08:00
! HELP-FC1-NEXT: -ffixed-form Process source files in fixed form
! HELP-FC1-NEXT: -ffixed-line-length=<value>
! HELP-FC1-NEXT: Use <value> as character line width in fixed mode
! HELP-FC1-NEXT: -ffree-form Process source files in free form
[flang][driver] Add support for `-fget-definition` This patch adds `-fget-definition` to `flang-new`. The semantics of this option are identical in both drivers. The error message in the "throwaway" driver is updated so that it matches the one from `flang-new` (which is auto-generated and cannot be changed easily). Tests are updated accordingly. A dedicated test for error handling was added: get-definition.f90 (for the sake of simplicity, getdefinition01.f90 no longer tests for errors). The `ParseFrontendArgs` function is updated so that it can return errors. This change is required in order to report invalid values following `-fget-definition`. The actual implementation of `GetDefinitionAction::ExecuteAction()` was extracted from f18.cpp (i.e. the bit that deals with `-fget-definition`). Depends on: https://reviews.llvm.org/D100556 Differential Revision: https://reviews.llvm.org/D100558
2021-04-14 18:43:14 +08:00
! HELP-FC1-NEXT: -fget-definition <value> <value> <value>
! HELP-FC1-NEXT: Get the symbol definition from <line> <start-column> <end-column>
[flang][driver] Add support for `-fget-symbols-sources` Adds support for `-fget-symbols-sources` in the new Flang driver. All relevant tests are updated to use the new driver when `FLANG_BUILD_NEW_DRIVER` is set. `RUN` lines in tests are updated so `-fsyntax-only` comes before `-fget-symbols-sources`. That's because: * both `-fsyntax-only` and `-fget-symbols-sources` are action flags, and * the new driver, flang-new, will only consider the right-most action flag. In other words, this change is needed so that the tests work with both `f18` (requires both flags) and `flang-new` (only considers the last action flag). Differential Revision: https://reviews.llvm.org/D98191
2021-03-09 00:54:11 +08:00
! HELP-FC1-NEXT: -fget-symbols-sources Dump symbols and their source code locations
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-FC1-NEXT: -fimplicit-none No implicit typing allowed unless overridden by IMPLICIT statements
! HELP-FC1-NEXT: -finput-charset=<value> Specify the default character set for source files
[flang][driver] Add -fintrinsic-modules-path option Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97080
2021-03-24 00:24:57 +08:00
! HELP-FC1-NEXT: -fintrinsic-modules-path <dir>
! HELP-FC1-NEXT: Specify where to find the compiled intrinsic modules
[flang][driver] Add options for -fdefault* and -flarge-sizes Add support for the following Fortran dialect options: - -default* - -flarge-sizes It also adds two test cases: # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`. # For checking if `fdefault-` arguments are processed properly. Also moves the Dialect related option parsing to a dedicated function and adds a member `defaultKinds()` to `CompilerInvocation` Depends on: D96032 Differential Revision: https://reviews.llvm.org/D96344
2021-03-04 00:28:11 +08:00
! HELP-FC1-NEXT: -flarge-sizes Use INTEGER(KIND=8) for the result type in size-related intrinsics
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-FC1-NEXT: -flogical-abbreviations Enable logical abbreviations
[flang][driver] Add `-fno-analyzed-objects-for-unparse` This patch adds a new option for the new Flang driver: `-fno-analyzed-objects-for-unparse`. The semantics are similar to `-funparse-typed-exprs-to-f18-fc` from `f18`. For consistency, the latter is replaced with `-fno-analyzed-objects-for-unparse`. The new option controls the behaviour of the unparser (i.e. the action corresponding to `-fdebug-unparse`). The default behaviour is to use the analyzed objects when unparsing. The new flag can be used to turn this off, so that the original parse-tree objects are used. The analyzed objects are generated during the semantic checks [1]. This patch also updates the semantics of `-fno-analyzed-objects-for-unparse`/`-funparse-typed-exprs-to-f18-fc` in `f18`, so that this flag is always taken into account when `Unparse` is used (this way the semantics in `f18` and `flang-new` are identical). The added test file is based on example from Peter Steinfeld. [1] https://github.com/llvm/llvm-project/blob/main/flang/docs/Semantics.md Differential Revision: https://reviews.llvm.org/D103612
2021-06-04 22:25:58 +08:00
! HELP-FC1-NEXT: -fno-analyzed-objects-for-unparse
! HELP-FC1-NEXT: Do not use the analyzed objects when unparsing
[flang] Add -fno-automatic, refine IsSaved() This legacy option (available in other Fortran compilers with various spellings) implies the SAVE attribute for local variables on subprograms that are not explicitly RECURSIVE. The SAVE attribute essentially implies static rather than stack storage. This was the default setting in Fortran until surprisingly recently, so explicit SAVE statements & attributes could be and often were omitted from older codes. Note that initialized objects already have an implied SAVE attribute, and objects in COMMON effectively do too, as data overlays are extinct; and since objects that are expected to survive from one invocation of a procedure to the next in static storage should probably be explicit initialized in the first place, so the use cases for this option are somewhat rare, and all of them could be handled with explicit SAVE statements or attributes. This implicit SAVE attribute must not apply to automatic (in the Fortran sense) local objects, whose sizes cannot be known at compilation time. To get the semantics of IsSaved() right, the IsAutomatic() predicate was moved into Evaluate/tools.cpp to allow for dynamic linking of the compiler. The redundant predicate IsAutomatic() was noticed, removed, and its uses replaced. GNU Fortran's spelling of the option (-fno-automatic) was added to the clang-based driver and used for basic sanity testing. Differential Revision: https://reviews.llvm.org/D114209
2021-11-19 03:48:42 +08:00
! HELP-FC1-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
[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 17:44:21 +08:00
! HELP-FC1-NEXT: -fno-debug-pass-manager Disables debug printing for the new pass manager
[flang] Produce proper "preprocessor output" for -E option Rename the current -E option to "-E -Xflang -fno-reformat". Add a new Parsing::EmitPreprocessedSource() routine to convert the cooked character stream output of the prescanner back to something more closely resembling output from a traditional preprocessor; call this new routine when -E appears. The new -E output is suitable for use as fixed form Fortran source to compilation by (one hopes) any Fortran compiler. If the original top-level source file had been free form source, the output will be suitable for use as free form source as well; otherwise there may be diagnostics about missing spaces if they were indeed absent in the original fixed form source. Unless the -P option appears, #line directives are interspersed with the output (but be advised, f18 will ignore these if presented with them in a later compilation). An effort has been made to preserve original alphabetic character case and source indentation. Add -P and -fno-reformat to the new drivers. Tweak test options to avoid confusion with prior -E output; use -fno-reformat where needed, but prefer to keep -E, sometimes in concert with -P, on most, updating expected results accordingly. Differential Revision: https://reviews.llvm.org/D106727
2021-07-24 07:41:04 +08:00
! HELP-FC1-NEXT: -fno-reformat Dump the cooked character stream in -E mode
[flang][driver] Add support for -fopenmp and -fopenacc Add support for the following options: * -fopenmp * -fopenacc Update OpenMP and OpenACC semantics tests to use the new driver if it is built, otherwise use f18. OpenMP tests that include `use omp_lib` or run `test_symbols.sh` have not been updated as they require options `-intrinsic-module-directory` and `-funparse-with-symbols` which are currently not implemented in the new driver. Similarly OpenACC tests that run `test_symbols.sh` have not been updated. This patch also moves semanticsContext to CompilerInvocation and creates it in CompilerInvocation#setSemanticsOpts so that the semantics context can use Fortran::parser::Options#features. Summary of changes: - Move semanticsContext to CompilerInvocation.h - Update OpenMP and OpenACC semantics tests that do not rely on `-intrinsic-module-directory` and `-funparse-with-symbols` to use %flang Differential Revision: https://reviews.llvm.org/D96032
2021-02-10 17:24:45 +08:00
! HELP-FC1-NEXT: -fopenacc Enable OpenACC
! HELP-FC1-NEXT: -fopenmp Parse OpenMP pragmas and generate parallel code.
[clang,flang] Add help text for -fsyntax-only Fix for the problem with displaying options `-fsyntax-only` in clang and flang-new in help Fix https://github.com/llvm/llvm-project/issues/57033 Before: ``` $ clang -help | grep syntax -objcmt-migrate-property-dot-syntax Enable migration of setter/getter messages to property-dot syntax ``` After: ``` $ clang -help | grep syntax -fsyntax-only Run the preprocessor, parser and semantic analysis stages -objcmt-migrate-property-dot-syntax Enable migration of setter/getter messages to property-dot syntax ``` Reviewed By: vzakhari, awarzynski, MaskRay, alexiprof Differential Revision: https://reviews.llvm.org/D131808
2022-08-19 17:53:27 +08:00
! HELP-FC1-NEXT: -fsyntax-only Run the preprocessor, parser and semantic analysis stages
[flang][driver] Add extension options and -finput-charset Add the following options: * -fimplicit-none and -fno-implicit-none * -fbackslash and -fno-backslash * -flogical-abbreviations and -fno-logical-abbreviations * -fxor-operator and -fno-xor-operator * -falternative-parameter-statement * -finput-charset=<value> Summary of changes: - Enable extensions in CompilerInvocation#ParseFrontendArgs - Add encoding_ to Fortran::frontend::FrontendOptions - Add encoding to Fortran::parser::Options Differential Revision: https://reviews.llvm.org/D96407
2021-02-05 05:11:22 +08:00
! HELP-FC1-NEXT: -fxor-operator Enable .XOR. as a synonym of .NEQV.
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-FC1-NEXT: -help Display available options
[flang][driver] Add support for the "-init-only" option Adding the `-init-only` option and corresponding frontend action to generate a diagnostic. `-init-only` vs `-test-io`: `-init-only` ignores the input (it never calls the prescanner) `-test-io` is similar to `-init-only`, but does read and print the input without calling the prescanner. This patch also adds a Driver test to check this action. Reviewed By: awarzynski, AMDChirag Differential Revision: https://reviews.llvm.org/D102849
2021-06-07 22:40:26 +08:00
! HELP-FC1-NEXT: -init-only Only execute frontend initialization
[flang][driver] Add support for `-I` in the new driver Add support for option -I in the new Flang driver. This will allow for included headers and module files in other directories, as the default search path is currently the working folder. The behaviour of this is consistent with the current f18 driver, where the current folder (i.e. ".") has the highest priority followed by the order of '-I's taking priority from first to last. Summary of changes: - Add SearchDirectoriesFromDashI to PreprocessorOptions, to be forwarded into the parser's searchDirectories - Add header files and non-functional module files to be used in regression tests. The module files are just text files and are used to demonstrated that paths specified with `-I` are taken into account when searching for .mod files. Differential Revision: https://reviews.llvm.org/D93453
2021-01-19 18:01:38 +08:00
! HELP-FC1-NEXT: -I <dir> Add directory to the end of the list of include search paths
[flang][driver] Add support for Frontend Plugins Introducing a plugin API and a simple HelloWorld Plugin example. This patch adds the `-load` and `-plugin` flags to frontend driver and the code around using custom frontend actions from within a plugin shared library object. It also adds to the Driver-help test to check the help option with the updated driver flags. Additionally, the patch creates a plugin-example test to check the HelloWorld plugin example runs correctly. As part of this, a new CMake flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built and for the test to run. This Plugin API has only been tested on Linux. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D106137
2021-08-12 18:42:08 +08:00
! HELP-FC1-NEXT: -load <dsopath> Load the named plugin (dynamic shared object)
[flang][driver] Add support for `-mllvm` This option is added in both `flang-new` (the compiler driver) and `flang-new -fc1` (the frontend driver). The semantics are consistent with `clang` and `clang -cc1`. As Flang does not run any LLVM passes when invoked with `-emit-llvm` (i.e. `flang-new -S -emit-llvm <file>`), the tests use `-S`/`-c`/`-emit-obj` instead. These options require an LLVM backend to be run by the driver to generate the output (this makese `-mllvm` relevant here). Differential Revision: https://reviews.llvm.org/D121374
2022-03-02 23:40:16 +08:00
! HELP-FC1-NEXT: -mllvm <value> Additional arguments to forward to LLVM's option processing
[flang][driver] Add support for `-mmlir` The semantics of `-mmlir` are identical to `-mllvm`. The only notable difference is that `-mmlir` options should be forwarded to MLIR rather than LLVM. Note that MLIR llvm::cl options are lazily constructed on demand (see the definition of options in PassManagerOptions.cpp). This means that: * MLIR global options are only visible when explicitly initialised and displayed only when using `-mmlir --help`, * Flang and LLVM global options are always visible and displayed when using either `-mllvm -help` or `-mmlir --help`. In other words, `-mmlir --help` is a superset of `-mllvm --help`. This is not ideal, but we'd need to refactor all option definitions in Flang and LLVM to improve this. I suggesting leaving this for later. Differential Revision: https://reviews.llvm.org/D123297
2022-04-07 17:47:23 +08:00
! HELP-FC1-NEXT: -mmlir <value> Additional arguments to forward to MLIR's option processing
[flang][driver] Add support for `-J/-module-dir` Add support for option -J/-module-dir in the new Flang driver. This will allow for including module files in other directories, as the default search path is currently the working folder. This also provides an option of storing the output module in the specified folder. Differential Revision: https://reviews.llvm.org/D95448
2021-02-05 00:13:04 +08:00
! HELP-FC1-NEXT: -module-dir <dir> Put MODULE files in <dir>
[flang][driver] Add support for `-module-suffix` This option is supported in `f18`, but not yet available in `flang-new`. It is required in order to call `flang-new` from the `flang` bash script. Differential Revision: https://reviews.llvm.org/D103613
2021-06-04 20:58:03 +08:00
! HELP-FC1-NEXT: -module-suffix <suffix> Use <suffix> as the suffix for module files (the default value is `.mod`)
[Flang][Driver] Add support for PIC This patch does the following: - Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new. tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this. - Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie" command line options. - Adds the above options to flang/Frontend/CodeGenOptions' data structure. - Sets the relocation model in the target machine, and - Sets module flags for the respective PIC/PIE type in LLVM IR. I have tried my best to replicate how clang does things. Differential Revision: https://reviews.llvm.org/D131533 Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
2022-08-23 01:24:49 +08:00
! HELP-FC1-NEXT: -mrelocation-model <value>
! HELP-FC1-NEXT: The relocation model to use
[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 19:42:37 +08:00
! HELP-FC1-NEXT: -nocpp Disable predefined and command line preprocessor macros
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-FC1-NEXT: -o <file> Write output to <file>
[flang][driver] Add options for -std=f2018 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97119
2021-03-26 01:02:05 +08:00
! HELP-FC1-NEXT: -pedantic Warn on language extensions
[Flang][Driver] Add support for PIC This patch does the following: - Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new. tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this. - Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie" command line options. - Adds the above options to flang/Frontend/CodeGenOptions' data structure. - Sets the relocation model in the target machine, and - Sets module flags for the respective PIC/PIE type in LLVM IR. I have tried my best to replicate how clang does things. Differential Revision: https://reviews.llvm.org/D131533 Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
2022-08-23 01:24:49 +08:00
! HELP-FC1-NEXT: -pic-is-pie File is for a position independent executable
! HELP-FC1-NEXT: -pic-level <value> Value for __PIC__
[flang][driver] Add support for Frontend Plugins Introducing a plugin API and a simple HelloWorld Plugin example. This patch adds the `-load` and `-plugin` flags to frontend driver and the code around using custom frontend actions from within a plugin shared library object. It also adds to the Driver-help test to check the help option with the updated driver flags. Additionally, the patch creates a plugin-example test to check the HelloWorld plugin example runs correctly. As part of this, a new CMake flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built and for the test to run. This Plugin API has only been tested on Linux. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D106137
2021-08-12 18:42:08 +08:00
! HELP-FC1-NEXT: -plugin <name> Use the named plugin action instead of the default action (use "help" to list available options)
[flang] Produce proper "preprocessor output" for -E option Rename the current -E option to "-E -Xflang -fno-reformat". Add a new Parsing::EmitPreprocessedSource() routine to convert the cooked character stream output of the prescanner back to something more closely resembling output from a traditional preprocessor; call this new routine when -E appears. The new -E output is suitable for use as fixed form Fortran source to compilation by (one hopes) any Fortran compiler. If the original top-level source file had been free form source, the output will be suitable for use as free form source as well; otherwise there may be diagnostics about missing spaces if they were indeed absent in the original fixed form source. Unless the -P option appears, #line directives are interspersed with the output (but be advised, f18 will ignore these if presented with them in a later compilation). An effort has been made to preserve original alphabetic character case and source indentation. Add -P and -fno-reformat to the new drivers. Tweak test options to avoid confusion with prior -E output; use -fno-reformat where needed, but prefer to keep -E, sometimes in concert with -P, on most, updating expected results accordingly. Differential Revision: https://reviews.llvm.org/D106727
2021-07-24 07:41:04 +08:00
! HELP-FC1-NEXT: -P Disable linemarker output in -E mode
[flang][driver] Add options for -std=f2018 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97119
2021-03-26 01:02:05 +08:00
! HELP-FC1-NEXT: -std=<value> Language standard to compile for
[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-25 01:34:27 +08:00
! HELP-FC1-NEXT: -S Only run preprocess and compilation steps
[flang][driver] Add -Xflang and make -test-io a frontend-only flang This patch adds support for `-Xflang` in `flang-new`. The semantics are identical to `-Xclang`. With the addition of `-Xflang`, we can modify `-test-io` to be a compiler-frontend only flag. This makes more sense, this flag is: * very frontend specific * to be used for development and testing only * not to be exposed to the end user Originally we added it to the compiler driver, `flang-new`, in order to facilitate testing. With `-Xflang` this is no longer needed. Tests are updated accordingly. Differential Revision: https://reviews.llvm.org/D96864
2021-02-17 22:13:29 +08:00
! HELP-FC1-NEXT: -test-io Run the InputOuputTest action. Use for development and testing only.
[flang][driver] Add support for `--target`/`--triple` This patch adds support for: * `--target` in the compiler driver (`flang-new`) * `--triple` in the frontend driver (`flang-new -fc1`) The semantics of these flags are inherited from `clangDriver`, i.e. consistent with `clang --target` and `clang -cc1 --triple`, respectively. A new structure is defined, `TargetOptions`, that will hold various Frontend options related to the target. Currently, this is mostly a placeholder that contains the target triple. In the future, it will be used for storing e.g. the CPU to tune for or the target features to enable. Additionally, the following target/triple related options are enabled [*]: `-print-effective-triple`, `-print-target-triple`. Definitions in Options.td are updated accordingly and, to facilated testing, `-emit-llvm` is added to the list of options available in `flang-new` (previously it was only enabled in `flang-new -fc1`). [*] These options were actually available before (like all other options defined in `clangDriver`), but not included in `flang-new --help`. Before this change, `flang-new` would just use `native` for defining the target, so these options were of little value. Differential Revision: https://reviews.llvm.org/D120246
2022-02-21 19:51:32 +08:00
! HELP-FC1-NEXT: -triple <value> Specify target triple (e.g. i686-apple-darwin9)
[flang][driver] Add support for `-D`, `-U` Add support for options -D and -U in the new Flang driver. Summary of changes: - Create PreprocessorOptions, to be used by the driver then translated into Fortran::parser::Options - Create CompilerInvocation::setFortranOpts to pass preprocessor options into the parser options - Add a dedicated method, Flang::AddPreprocessingOptions, to extract preprocessing options from the driver arguments into the preprocessor command arguments Macros specified like -DName will default to definition 1. When defining macros, the new driver will drop anything after an end-of-line character. This is consistent with gfortran and clang, but different to what currently f18 does. However, flang (which is a bash wrapper for f18), also drops everything after an end-of-line character. So gfortran-like behaviour felt like the natural choice. Test is added to demonstrate this behaviour. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D93401
2021-01-06 23:42:24 +08:00
! HELP-FC1-NEXT: -U <macro> Undefine macro <macro>
[flang][driver] Make --version and -version consistent with clang This patch makes -version valid, and --version invalid, for flang-new -fc1. The invocation flang-new --version remains valid. This behaviour is consistent with clang (and with clang -cc1 and clang -cc1as). Previously, flang-new -fc1 accepted --version (as per Options.td), but the frontend driver acutally checks for -version. As a result, flang-new -fc1 --version triggered no action, emitted no message, and stalled waiting for standard input. Fixes #51438 Reviewed By: PeteSteinfeld, awarzynski Differential Revision: https://reviews.llvm.org/D122542
2022-03-29 02:28:51 +08:00
! HELP-FC1-NEXT: -version Print the compiler version
[flang][driver] Add options for -Werror With the option given, warnings are treated as error. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D98657
2021-04-06 00:41:46 +08:00
! HELP-FC1-NEXT: -W<warning> Enable the specified warning
[flang] Introduce DiagnosticConsumer classes in libflangFrontend Currently Flang uses TextDiagnostic, TextDiagnosticPrinter & TestDiagnosticBuffer classes from Clang (more specifically, from libclangFrontend). This patch introduces simplified equivalents of these classes in Flang (i.e. it removes the dependency on libclangFrontend). Flang only needs these diagnostics classes for the compiler driver diagnostics. This is unlike in Clang in which similar diagnostic classes are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the implementations introduced here are relatively basic. We can extend them in the future if this is required. This patch also enhances how the diagnostics are printed. In particular, this is the diagnostic that you'd get _before_ the changes introduced here (no text formatting): ``` $ bin/flang-new error: no input files ``` This is the diagnostic that you get _after_ the changes introduced here (in terminals that support it, the text is formatted - bold + red): ``` $ bin/flang-new flang-new: error: no input files ``` Tests are updated accordingly and options related to enabling/disabling color diagnostics are flagged as supported by Flang. Reviewed By: sameeranjoshi, CarolineConcatto Differential Revision: https://reviews.llvm.org/D87774
2020-10-06 00:42:00 +08: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 19:33:19 +08:00
! ERROR: error: unknown argument '-helps'; did you mean '-help'