[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

[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

show more ...

[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`.

[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

show more ...

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

Differential Revision: https://reviews.llvm.org/D118631

show more ...

[flang][driver][nfc] Fix capitalisation

As pointed out in https://reviews.llvm.org/D93401, some methods in the
Flang driver are named inconsistently. The driver strives to follow
Flang's C++ style [

[flang][driver][nfc] Fix capitalisation

As pointed out in https://reviews.llvm.org/D93401, some methods in the
Flang driver are named inconsistently. The driver strives to follow
Flang's C++ style [1] and this patch updates these methods accordingly.

[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md

Differential Revision: https://reviews.llvm.org/D118381

show more ...

Include missing "llvm/Support/Path.h" in "flang/lib/Frontend/CompilerInvocation.cpp"

[flang] Make the frontend driver error out when requesting multiple actions

With this change, the following invocations will be treated as errors
(multiple actions are specified):
```
$ flang-new -f

[flang] Make the frontend driver error out when requesting multiple actions

With this change, the following invocations will be treated as errors
(multiple actions are specified):
```
$ flang-new -fc1 -E -fsyntax-only file.95
$ flang-new -fc1 -fsyntax-only -fdebug-dump-symbols file.95
```
In the examples above it is not clear whether it is `-fsyntax-only` or
the other action that is run (i.e. `-E` or `-fdebug-dump-symbols`). It
makes sense to disallow such usage. This should also lead to cleaner and
clearer tests (the `RUN` lines using `%flang_fc1` will only allow one
action).

This change means that `flang-new -fc1` and `clang -cc1` will behave
differently when multiple action options are specified. As frontend
drivers are mostly used by compiler developers, this shouldn't affect or
confuse the compiler end-users. Also, `flang-new` and `clang` remain
consistent.

Tests are updated accordingly. More specifically, I've made sure that
every test specifies only one action. I've also taken the opportunity to
simplify "multiple-input-files.f90" a bit.

Differential Revision: https://reviews.llvm.org/D111781

show more ...

[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 n

[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

show more ...

[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 arou

[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

show more ...

[flang][driver] Delete `f18` (i.e. the old Flang driver)

This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with

[flang][driver] Delete `f18` (i.e. the old Flang driver)

This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].

With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).

LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.

The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.

[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177

Differential Revision: https://reviews.llvm.org/D105811

show more ...

[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 t

[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

show more ...

[flang][nfc] Fix variable names in `FrontendOptions` & `PreprocessorOptions`

As all member variables in `FrontendOptions` and `PreprocessorOptions`
are public, we should be naming them as `variable`

[flang][nfc] Fix variable names in `FrontendOptions` & `PreprocessorOptions`

As all member variables in `FrontendOptions` and `PreprocessorOptions`
are public, we should be naming them as `variable` rather than
`variable_` [1]. This patch fixes that.

Also, `FrontendOptions` & `PreprocessorOptions` are re-defined as a
structs rather than classes (all fields are meant to be public).

[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md#naming

Differential Revision: https://reviews.llvm.org/D107062

show more ...

[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 char

[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

show more ...

[flang] Revert "PoC for Flang Driver Plugins"

This patch has not been reviewed and was commited by accident.

This reverts commit 788a5d4afe6407e647454a9832a7b4a27fba06bf.

PoC for Flang Driver Plugins

[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-expr

[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

show more ...

[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 `-fdebu

[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

show more ...

[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 t

[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

show more ...

[flang][driver] Add checks for missing option arguments

With this patch, the following invocation of the frontend driver will
return an error:
```
flang-new -fc1 input-file.f90 -o
```
Similar logic

[flang][driver] Add checks for missing option arguments

With this patch, the following invocation of the frontend driver will
return an error:
```
flang-new -fc1 input-file.f90 -o
```
Similar logic applies to other options that require arguments.

Similar checks are already available in the compiler driver, flang-new
(that's implemented in clangDriver).

Differential Revision: https://reviews.llvm.org/D103554

show more ...

[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.

D

[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

show more ...

[Clang] remove text extension from diag::err_drv_invalid_value_with_suggestion

This hinders translations, as per:
https://clang.llvm.org/docs/InternalsManual.html#the-format-string

Reviewed By: Mas

[Clang] remove text extension from diag::err_drv_invalid_value_with_suggestion

This hinders translations, as per:
https://clang.llvm.org/docs/InternalsManual.html#the-format-string

Reviewed By: MaskRay, xbolva00

Differential Revision: https://reviews.llvm.org/D101387

show more ...

[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"

[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

show more ...

[flang][driver] Refactor methods for parsing options (nfc)

This is just a small update that makes sure that errors arising from
parsing command-line options are captured more visibly. Also, all
pars

[flang][driver] Refactor methods for parsing options (nfc)

This is just a small update that makes sure that errors arising from
parsing command-line options are captured more visibly. Also, all
parsing methods will now consistently return either a bool ("may fail")
or void ("never fails").

An instance of `InputKind` coming from `-x` is added to
`FrontendOptions` rather then being returned from `ParseFrontendArgs`.
It's currently not used, but we will require it shortly. In particular,
once code-generation is available we will use it to differentiate
between LLVM IR and Fortran input. `FrontendOptions` is a very suitable
place to keep it.

This changes don't affect the error reporting in the driver. In this
respect these are non-functional-changes. However, it will simplify
things in the forthcoming patches in which we may need a better error
tracking/recovery mechanism.

Differential Revision: https://reviews.llvm.org/D100556

show more ...

[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

[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

show more ...

[flang][driver] Fix `-fdebug-dump-provenance`

The -fdebug-dump-provenance flag is meant to be used with
needProvenanceRangeToCharBlockMappings set to true. This way, extra
mapping is generated that

[flang][driver] Fix `-fdebug-dump-provenance`

The -fdebug-dump-provenance flag is meant to be used with
needProvenanceRangeToCharBlockMappings set to true. This way, extra
mapping is generated that allows e.g. IDEs to retrieve symbol's scope
(offset into cooked character stream) based on symbol's source code
location. This patch makes sure that this option is set when using
-fdebug-dump-provenance.

With this patch, the implementation of -fdebug-dump-provenance in
`flang-new -fc1` becomes consistent with `f18`. The corresponding LIT
test is updated so that it can be shared with `f18`. I refined it a bit
so that:
* it becomes a frontend-only test
* it's stricter about the expected output

Differential Revision: https://reviews.llvm.org/D98847

show more ...

[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 gfort

[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

show more ...