[flang][driver] Fix opt-level option parsing

This update makes sure that `flang-new -O2 -O0` will run at `-O0` rather
than `-O2`.

This bug was identified and originally fixed by Vyacheslav Zakharin

[flang][driver] Fix opt-level option parsing

This update makes sure that `flang-new -O2 -O0` will run at `-O0` rather
than `-O2`.

This bug was identified and originally fixed by Vyacheslav Zakharin in
https://reviews.llvm.org/D130035. I've extracted the fix into a separate
patch.

co-authored by: Vyacheslav Zakharin <[email protected]>

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

show more ...

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

[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

show more ...

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

[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 <[email protected]>

Reviewed By: rovka

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

show more ...

[flang][driver] Make `flang-new -fc1` accept MLIR files

This relatively small change will allow Flang's frontend driver,
`flang-new -fc1`, to consume and parse MLIR files. Semantically (i.e.
from u

[flang][driver] Make `flang-new -fc1` accept MLIR files

This relatively small change will allow Flang's frontend driver,
`flang-new -fc1`, to consume and parse MLIR files. Semantically (i.e.
from user's perspective) this is identical to reading LLVM IR files.

Two file extensions are associated with MLIR files: .fir and .mlir. Note
that reading MLIR files makes only sense when running one of the
code-generation actions, i.e. when using one of the following action
flags: -S, -emit-obj, -emit-llvm, -emit-llvm-bc.

The majority of tests that required `tco` to run are updated to also run
with `flang-new -fc1`. A few tests are updated to use `fir-opt` instead
of `tco` (that's the preferred choice when testing a particular MLIR
pass). basic-program.fir is not updated as that test is intended to
verify the behaviour of `tco` specifically.

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

show more ...

[flang][driver] Fix support for `-x`

Until now, `-x` wasn't really taken into account in Flang's compiler and
frontend drivers. `flang-new` and `flang-new -fc1` only recently gained
powers to consum

[flang][driver] Fix support for `-x`

Until now, `-x` wasn't really taken into account in Flang's compiler and
frontend drivers. `flang-new` and `flang-new -fc1` only recently gained
powers to consume inputs other than Fortran files and that's probably
why this hasn't been noticed yet.

This patch makes sure that `-x` is supported correctly and consistently
with Clang. To this end, verification is added when reading LLVM IR
files (i.e. IR modules are verified with `llvm::verifyModule`). This
way, LLVM IR parsing errors are correctly reported to Flang users. This
also aids testing.

With the new functionality, we can verify that `-x ir` breaks
compilation for e.g. Fortran files and vice-versa. Tests are updated
accordingly.

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

show more ...

[flang][driver] Switch to the MLIR coding style in the driver (nfc)

This patch re-factors the driver code in LLVM Flang (frontend +
compiler) to use the MLIR style. For more context, please see:
htt

[flang][driver] Switch to the MLIR coding style in the driver (nfc)

This patch re-factors the driver code in LLVM Flang (frontend +
compiler) to use the MLIR style. For more context, please see:
https://discourse.llvm.org/t/rfc-coding-style-in-the-driver/

Most changes here are rather self-explanatory. Accessors are renamed to
be more consistent with the rest of LLVM (e.g. allSource -->
getAllSources). Additionally, MLIR clang-tidy files are added in the
affected directories.

clang-tidy and clang-format files were copied from MLIR. Small
additional changes are made to silence clang-tidy/clang-format
warnings.

[1] https://mlir.llvm.org/getting_started/DeveloperGuide/

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

show more ...

[flang][driver] Define the default frontend driver triple

*SUMMARY*
Currently, the frontend driver assumes that a target triple is either:
* provided by the frontend itself (e.g. when lowering and

[flang][driver] Define the default frontend driver triple

*SUMMARY*
Currently, the frontend driver assumes that a target triple is either:
* provided by the frontend itself (e.g. when lowering and generating
code),
* specified through the `-triple/-target` command line flags.

If `-triple/-target` is not used, the frontend will simply use the host
triple.

This is going to be insufficient when e.g. consuming an LLVM IR file
that has no triple specified (reading LLVM files is WIP, see D124667).
We shouldn't require the triple to be specified via the command line in
such situation. Instead, the frontend driver should contain a good
default, e.g. the host triple.

This patch updates Flang's `CompilerInvocation` to do just that, i.e.
defines its default target triple. Similarly to Clang:
* the default `CompilerInvocation` triple is set as the host triple,
* the value specified with `-triple` takes precedence over the frontend
driver default and the current module triple,
* the frontend driver default takes precedence over the module triple.

*TESTS*
This change requires 2 unit tests to be updated. That's because relevant
frontend actions are updated to assume that there's always a valid
triple available in the current `CompilerInvocation`. This update is
required because the unit tests bypass the regular `CompilerInvocation`
set-up (in particular, they don't call
`CompilerInvocation::CreateFromArgs`). I've also taken the liberty to
disable the pre-precossor formatting in the affected unit tests as well
(it is not required).

No new tests are added. As `flang-new -fc1` does not support consuming
LLVM IR files just yet, it is not possible to compile an LLVM IR file
without a triple. More specifically, atm all LLVM IR files are generated
and stored internally and the driver makes sure that these contain a
valid target triple. This is about to change in D124667 (which adds
support for reading LLVM IR/BC files) and that's where tests for
exercising the default frontend driver triple will be added.

*WHAT DOES CLANG DO?*
For reference, the default target triple for Clang's
`CompilerInvocation` is set through option marshalling infra [1] in
Options.td. Please check the definition of the `-triple` flag:
```
def triple : Separate<["-"], "triple">,
HelpText<"Specify target triple (e.g. i686-apple-darwin9)">,
MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">,
AlwaysEmit, Normalizer<"normalizeTriple">;
```
Ideally, we should re-use the marshalling infra in Flang.

[1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure

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

show more ...

[flang][driver] NFC: Make code more in line with LLVM style

This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It
also:
* replaces `CreateFrontendBaseAction` with `CreateFronten

[flang][driver] NFC: Make code more in line with LLVM style

This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It
also:
* replaces `CreateFrontendBaseAction` with `CreateFrontendAction`
(only one method is needed ATM, this change removes the extra
indirection)
* removes `InvalidAction` from the `ActionKind` enum (I don't think it
adds much and keeping it would mean adding a new void case in
`CreateFrontendAction`)
* sets the default frontend action in FrontendOptions.h to
`ParseSyntaxOnly` (note that this is still overridden independently
in `ParseFrontendArg` in CompilerInvocation.cpp)

No new functionality is added, hence no tests.

[1] https://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

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

show more ...

[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

[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

show more ...

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

[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

show more ...

[Driver] Simplify -f[no-]diagnostics-color handling. NFC

Make them aliases for -f[no-]color-diagnostics.

[flang][cmake] Make CMake copy "omp_lib.h" into the build directory

Any header or module file in the Flang source directory is of no use to
the compiler unless it is copied into the build directory.

[flang][cmake] Make CMake copy "omp_lib.h" into the build directory

Any header or module file in the Flang source directory is of no use to
the compiler unless it is copied into the build directory. Indeed, all
compiler search paths are relative to the compiler executable (flang-new
in our case). Hence, "omp_lib.h" should be copied into the build
directory alongside other compiler-provided files that can be "included"
(header files) or "used" (module files).

For now, "omp_lib.h" is copied into "<build-dir>/include/flang/OpenMP".
We may decide to change this in future. For example, Clang copies a
bunch of runtime headers into “<build-dir>/lib/clang/<version-number>”.
We could also consider using a similar header from a different
sub-project.

Flang's driver search path is updated accordingly. A rule for
"installing" the "omp_lib.h" header is _yet to be added_ (we will also
need to determine the suitable location for this).

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

show more ...

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

[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

show more ...

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

[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

show more ...

[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

[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

show more ...

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

[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

show more ...

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