Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init |
|
#
3a1513c1 |
| 26-Jan-2021 |
Faris Rehman <faris.rehman@arm.com> |
[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) Additio
[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
show more ...
|
Revision tags: llvmorg-11.1.0-rc2 |
|
#
aba24c15 |
| 21-Jan-2021 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
[flang][driver] Move fixed/free from detection out of FrontendAction API
All Fortran options should be set in `CompilerInstance` (via its `CompilerInvocation`) before any of `FrontendAction` is ente
[flang][driver] Move fixed/free from detection out of FrontendAction API
All Fortran options should be set in `CompilerInstance` (via its `CompilerInvocation`) before any of `FrontendAction` is entered - that's one of the tasks of the driver. However, this is a bit tricky with fixed and free from detection introduced in https://reviews.llvm.org/D94228.
Fixed-free form detection needs to happen: * before any frontend action (we need to specify `isFixedForm` in `Fortran::parser::Options` before running any actions) * separately for every input file (we might be compiling multiple Fortran files, some in free form, some in fixed form) In other words, we need this to happen early (before any `FrontendAction`), but not too early (we need to know what the current input file is). In practice, `isFixedForm` can only be set later than other options (other options are inferred from compiler flags). So we can't really set all of them in one place, which is not ideal.
All changes in this patch are NFCs (hence no new tests). Quick summary: * move fixed/free form detection from `FrontendAction::ExecuteAction` to `CompilerInstance::ExecuteAction` * add a bool flag in `FrontendInputFile` to mark a file as fixed/free form * updated a few comments
Differential Revision: https://reviews.llvm.org/D95042
show more ...
|
Revision tags: llvmorg-11.1.0-rc1 |
|
#
7809fa20 |
| 06-Jan-2021 |
Faris Rehman <faris.rehman@arm.com> |
[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
[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
show more ...
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
#
7d246cb1 |
| 08-Dec-2020 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
[flang][driver] Add support for `-fsyntax-only`
The behaviour triggered with this flag is consistent with `-fparse-only` in `flang` (i.e. the throwaway driver). This new spelling is consistent with
[flang][driver] Add support for `-fsyntax-only`
The behaviour triggered with this flag is consistent with `-fparse-only` in `flang` (i.e. the throwaway driver). This new spelling is consistent with Clang and gfortran, and was proposed and agreed on for the new driver in [1].
This patch also adds some minimal logic to communicate whether the semantic checks have failed or not. When semantic checks fail, a frontend driver error is generated. The return code from the frontend driver is then determined by checking the driver diagnostics - the presence of driver errors means that the compilation has failed. This logic is consistent with `clang -cc1`.
[1] http://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html
Differential Revision: https://reviews.llvm.org/D92854
show more ...
|
Revision tags: llvmorg-11.0.1-rc1 |
|
#
d28de0d7 |
| 27-Oct-2020 |
Caroline Concatto <caroline.concatto@arm.com> |
[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 preproces
[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
show more ...
|
#
9ffb5b04 |
| 28-Oct-2020 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
[flang][driver] Rename the accessors/mutators (NFC)
As per point 3 in [1]:
``` Accessor member functions are named with the non-public data member's name, less the trailing underscore. Mutator mem
[flang][driver] Rename the accessors/mutators (NFC)
As per point 3 in [1]:
``` Accessor member functions are named with the non-public data member's name, less the trailing underscore. Mutator member functions are named set_... ```
Originally we just followed the LLVM's style, which is incompatible with Flang. This patch renames the accessors and mutators accordingly.
`getDiagnostics` and `GetDiagnostics` are replaced with one accessor: `diagnostics`. `SetDiagnostics` was neither implemented nor used, so it's deleted.
[1] https://github.com/llvm/llvm-project/blob/master/flang/docs/C++style.md#naming
Differential Revision: https://reviews.llvm.org/D90300
show more ...
|
#
4c5906cf |
| 24-Oct-2020 |
Caroline Concatto <caroline.concatto@arm.com> |
[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
[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
show more ...
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6 |
|
#
8d51d37e |
| 05-Oct-2020 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
[flang] Introduce DiagnosticConsumer classes in libflangFrontend
Currently Flang uses TextDiagnostic, TextDiagnosticPrinter & TestDiagnosticBuffer classes from Clang (more specifically, from libclan
[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
show more ...
|
Revision tags: llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
#
257b2971 |
| 11-Sep-2020 |
Caroline Concatto <caroline.concatto@arm.com> |
[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
[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
show more ...
|