If CMAKE_CROSSCOMPILING, then the newly built flang-new executable was
cross compiled and thus can't be executed on the build system, and thus
can't be used for generating module files.
Differential Revision: https://reviews.llvm.org/D130349
This is a follow-up of https://reviews.llvm.org/D125832
(see also https://reviews.llvm.org/D125788 for more context). It simply
removes any remaining references to the `flang` bash script. Note that
that `flang-to-external-fc` remains intact.
This felt worthwhile mentioning in the release notes, which have not
been updated since LLVM 12 (we are approaching LLVM 15 now). I took the
liberty of removing all of the out-dated content and added a note about
the renaming.
Differential Revision: https://reviews.llvm.org/D127094
Our ultimate goal is to rename `flang-new` as `flang`. This is "Step 1"
in which we only rename the bash wrapper script, `flang`, as
`flang-to-external-fc`. The new name more accurately reflects what the
wrapper script does.
With this patch, `flang` becomes a symbolic link pointing to
`flang-to-external-fc`. This allows a smooth transmission for any
buildbots that use this script. Once the buildbots are reconfigured to
use the updated name, CMake rule for the symbolic link will be removed.
For more context see:
* https://discourse.llvm.org/t/rename-flang-new-as-flang,
* https://reviews.llvm.org/D125788.
Differential Revision: https://reviews.llvm.org/D125832
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
The intrinsic module IEEE_ARITHMETIC must incorporate the public
names from the intrisic module IEEE_EXCEPTIONS. Rename IEEE_EXCEPTIONS
to __Fortran_ieee_exceptions so that it won't clash with the
nonintrinsic namespace, establish a new intrinic IEEE_EXCEPTIONS
module that USEs it, and add a USE to IEEE_ARITHMETIC.
Updated to use STREQUAL rather than ambiguous MATCHES in
the CMakeLists.txt file.
Differential Revision: https://reviews.llvm.org/D121490
The intrinsic module IEEE_ARITHMETIC must incorporate the public
names from the intrisic module IEEE_EXCEPTIONS. Rename IEEE_EXCEPTIONS
to __Fortran_ieee_exceptions so that it won't clash with the
nonintrinsic namespace, establish a new intrinic IEEE_EXCEPTIONS
module that USEs it, and add a USE to IEEE_ARITHMETIC.
Differential Revision: https://reviews.llvm.org/D121490
As per https://github.com/flang-compiler/f18-llvm-project/issues/1344,
the `flang` bash script works fine with 4.4.19 and requiring
4.4.23 is too restrictive. Rather than keep updating the patch level,
this patch removes this particular check (so that it will only check the
major and minor versions instead).
As this is both rather straightforward and urgent, I'm merging this
without a review.
The `flang` wrapper script has been written in a relatively modern
version of Bash and it fails on systems with older versions. This patch
makes the script check the version of Bash being used to run it and
generates an error when unsupported version is used.
This was discussed in more detail in:
* https://github.com/flang-compiler/f18-llvm-project/issues/1344.
Many thanks to Anthony Cabrera for the suggestion and for identifying
the oldest version of Bash that we can use here.
Differential Revision: https://reviews.llvm.org/D116608
This patch updates the `flang` bash scripts to differentiate between
object files provided by the user and intermediate object files
generated by the script. The latter are an "implementation detail" that
should not be visible to the end user (i.e. deleted before the scripts
exits). The former should be preserved.
Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1348
Differential Revision: https://reviews.llvm.org/D116590
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115569
Rearrange the contents of __builtin_* module files a little and
make sure that semantics implicitly USEs the module __Fortran_builtins
before processing each source file. This ensures that the special derived
types for TEAM_TYPE, EVENT_TYPE, LOCK_TYPE, &c. exist in the symbol table
where they will be available for use in coarray intrinsic function
processing.
Update IsTeamType() to exploit access to the __Fortran_builtins
module rather than applying ad hoc name tests. Move it and some
other utilities from Semantics/tools.* to Evaluate/tools.* to make
them available to intrinsics processing.
Add/correct the intrinsic table definitions for GET_TEAM, TEAM_NUMBER,
and THIS_IMAGE to exercise the built-in TEAM_TYPE as an argument and
as a result.
Add/correct/extend tests accordingly.
Differential Revision: https://reviews.llvm.org/D110356
We are only adding this in `flang` - the bash wrapper script for the
driver. We don't have any specific plans to support `-M{fixed|free}` in
`flang-new` (i.e. the actual driver).
That feature was requested by one of our users.
Differential Revision: https://reviews.llvm.org/D107081
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
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
This patch only modifies `flang` - the bash wrapper script.
`-fopenmp`/`-fopenacc` are required to enable the OpenMP/OpenACC
extension in the frontend and to make sure that the required libraries
are linked when generating the final binary. This patch makes sure that
`-fopnemp`/`-fopenacc` is used for both unparsing and the code
generation (via the host compiler).
Differential Revision: https://reviews.llvm.org/D106871
`-Mfixed` is not supported by the new driver and hence
`flang`, the bash wrapper script, forwards it to the host compiler.
The forwarded options are used by the host compiler when compiling the
unparsed files. As the unparsed source files are always in the free
form, forwarding `-Mfixed` is problematic.
With this patch, `-Mfixed` (and `-Mfree` for consistency) will be
ignored altogether. The user will only see a warning. This is not a
particularly sound approach, but `flang` is only a temporary solution
for us and this workaround is a fair compromise.
Differential Revision: https://reviews.llvm.org/D106428
In the `flang` bash script, we need to be careful _when_ to use <output>
from `flang -c -o <output> <input>` when generating the relocatable
output file name.
In particular, we should use it in this case:
```compilation only
flang -c -o <output> <input>
```
but leave it for the final executable here:
```compile, assemble and link
flang -o <output> <input>
```
This change is implemented in `get_relocatable_name`.
I've also taken the liberty to fix how errors from sub-commands are
reported (without this change, `flang` always returns `0` on failure).
This is implemented in `main`.
Differential Revision: https://reviews.llvm.org/D105896
This patch makes sure that the base name of the temporary unparsed files
(generated by the `flang` bash script) are randomised and unique to a
particular invocation of the script. Otherwise, we cannot reliably run
the script in parallel.
Differential Revision: https://reviews.llvm.org/D106052
Currently, `flang -c file.f` generates `flang_unparsed_source_file_0.o`.
This is incorrect. This patch:
* simplifies the logic around output filename generation, and
* makes sure that `file.o` is produced instead of e.g.
`flang_unparsed_source_file_0.o` when using the `-c` flag
The output filename generation is moved to a dedicated function. I've
also made a few minor improvements, e.g. marked variables as local,
added comments, refined error messages.
Differential Revision: https://reviews.llvm.org/D105546
The bash wrapper script, `flang`, calls `flang-new -fc1` under the hood,
which does not support `--version` (this is consistent with `clang -cc1
--version`). This change is needed for `flang --version` to work as
expected.
Note that `flang --version` (the Flang bash wrapper script for the
compiler driver) gives rather minimal output compared to `flang-new
--version` (the Flang compiler driver). As the wrapper script is just a
temporary solution for us, this should be sufficient.
Differential Revision: https://reviews.llvm.org/D105352
Until now, `f18` would:
1. Use Flang to unparse the input files
2. Call an external Fortran compiler to compile the unparsed source
files (generated in step 1)
With this patch, `f18` will stop after unparsing the input source files,
i.e. step 1 above. The `flang` bash script will take care of step 2,
i.e. calling an external Fortran compiler driver to compile them. This
way:
* the functionality of `f18` is reduced - it will only drive Flang (as
opposed to delegating code-generation to an external tool on top of
this)
* we will able to switch between `f18` and `flang-new` for unparsing before
an external Fortran compiler is called for code-generation
The updated `flang` bash script needs to specify the output file when
using the `-fdebug-unparse` action. Both `f18` and `flang-new` have been
updated accordingly.
These changes were discussed in [1] as a requirement for replacing `f18`
with `flang-new`.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-April/000677.html
Differential Revision: https://reviews.llvm.org/D103177
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
In error recovery situations, the mappings from source locations
to scopes were failing in a way that tripped some asserts.
Specifically, FindPureProcedureContaining() wasn't coping well
when starting at the global scope. (And since the global scope
no longer has a source range, clean up the Semantics constructor
to avoid confusion.)
Differential Revision: https://reviews.llvm.org/D103567
Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing. This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.
There were two sources of the bogus errors. One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).
The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.
Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.
Differential Revision: https://reviews.llvm.org/D101001
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
`%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
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
The build was putting .mod files for intrinsic modules in
tools/flang/include/flang but the install puts them in include/flang,
as does the out-of-tree build. This confused things for the driver.
This change makes the build consistent with the install and simplifies
the flang script accordingly.
Also, clean up the cmake commands for building the .mod files.
Differential Revision: https://reviews.llvm.org/D98522
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
This patch provides a fix for the `fdefault-*` family in f18
(Please consult `D96344` for details)
Differential Revision: https://reviews.llvm.org/D97724
Add -J to the f18 driver for compatibility with gfortran.
Add -module-dir for compatibility with the new flang driver.
They both set the output directory for .mod files and add the
directory to the search list. -module still only does the former.
Clean up the new driver test to match.
Differential Revision: https://reviews.llvm.org/D97164
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
The following _action_ options are always used with `-fsyntax-only`
(also an _action_ option):
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
This patch makes the above options imply `-fsyntax-only`.
From the perspective of `f18` this change saves typing and is otherwise
a non-functional change. But it will simplify things in the new driver,
`flang-new`, in which only the last action option is taken into account
and executed. In other words, the following would only run
`-fsyntax-only`:
```
flang-new -fdebug-dump-symbols -fsyntax-only <input>
```
whereas this would only run `-fdebug-dump-symbols`:
```
flang-new -fsyntax-only -fdebug-dump-symbols <input>
```
Differential Revision: https://reviews.llvm.org/D96528
Avoid spurious and confusing macro replacements from things like
-DPIC on Fortran source files whose suffixes indicate that preprocessing
is not expected.
Add gfortran-like "-cpp" and "-nocpp" flags to f18 to force predefinition
of macros independent of the source file suffix.
Differential Revision: https://reviews.llvm.org/D96464
Martin Storsjö