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
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
The algorithm for Fw.d output will drive binary to decimal conversion for
an initial fixed number of digits, then adjust that number based on the
result's exposent. For value close to a power of ten, this adjustment
process wouldn't terminate; e.g., formatting 9.999 as F10.2 would start
with 1e2, boost the digits to 2, get 9.99e1, decrease the digits, and loop.
Solve by refusing to boost the digits a second time.
Differential Revision: https://reviews.llvm.org/D107490
Like the similar legacy extension FLOAT(), DFLOAT() represents a
conversion from default integer to DOUBLE PRECISION. Rewrite
into a conversion operation.
Differential Revision: https://reviews.llvm.org/D107489
This file was previously included transitively via `mlir/Transforms/Passes.h`, but the include has been removed from that file.
Differential Revision: https://reviews.llvm.org/D107455
Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.
subroutine subr(dummy)
interface
subroutine dummy(x)
real :: x
end subroutine
end interface
! ...
end subroutine
but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail. Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.
Differential Revision: https://reviews.llvm.org/D106697
The result expression for the analysis of a Component is not (longer)
valid in the expression traversal framework used by IsSimplyContiguousHelper
now that it has a tri-state result. Fix so that any result of
analyzing the component symbol is required to be true, not just
present.
Differential Revision: https://reviews.llvm.org/D106693
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
Port external-io test to use GTest. Remove Runtime tests directory.
Rename RuntimeGTest directory to Runtime.
This is the last in a series of patches which ported tests from the old
flang/unittests/Runtime test directory to use GTest in a temporary
unittest directory under flang/unittests/RuntimeGTest. Now that all the
tests in the old directory have been ported to use GTest, the old
directory has been removed and the GTest directory has been renamed to
flang/unittests/Runtime.
Differential Revision: https://reviews.llvm.org/D105315
Reviewed by: Meinersbur, awarzynski
to fail due to warnings as errors. Note that I could not reproduce the
problem locally, but based on the messages, I think this change will fix
the errors.
Differential Revision: https://reviews.llvm.org/D107120
accidentally used int64 when they should have been int32. This lead to
a Windows build unit test error (Linux did not catch the problem).
Differential Revision: https://reviews.llvm.org/D107107
result descriptor (e.g., maxloc, minloc, maxval, minval, all, any, count,
parity, findloc, etc.)
Also add a scalar case for these intrinsic unit tests.
Differential Revision: https://reviews.llvm.org/D106820
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
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)
Differential Revision: https://reviews.llvm.org/D105149
According to C7109, "A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, or where explicitly allowed in
16.9 as an actual argument of an intrinsic procedure." This change
enforces that constraint for output list items.
I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.
I also added a test.
This change stemmed from the following issue --
https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108
Differential Revision: https://reviews.llvm.org/D106893
`-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
Since BOZ literal arguments are typeless, we cannot know how to pass them as
actual arguments to procedures with implicit interfaces. This change avoids
the problem by emitting an error message in such situations.
This change stemmed from the following issue --
https://github.com/flang-compiler/f18-llvm-project/issues/794
Differential Revision: https://reviews.llvm.org/D106831
Fix the external-io unittest under Windows.
In particular, fixes the following issues:
1. When creating a temporary file, open it with read+write permissions
using the _O_RDWR flag. _S_IREAD and _S_IWRITE are for the file
permissions of the created file.
2. _chsize returns 0 on success (just like ftruncate).
3. To set a std::optional, use its assign-operator overload instead of
getting a reference to its value and overwrite that. The latter is
invalid if the std::optional has no value, and is caught by
msvc's debug STL.
The non-GTest unittest is currently not executed under Windows because
of the added .exe extension to the output file: external-io.text.exe.
llvm-lit skips the file because .exe is not in the lists of test
suffixes (.test is). D105315 is going to change that by converting it
to a GTest-test.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106726
When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record. When doing a BACKSPACE
after an explicit ENDFILE statement, the position afterwards
must be upon the endfile record.
Attempts to join list-directed delimited character input across
record boundaries was due to a bad reading of the standard
and has been deleted, now that the requirements are better understood.
This problem would cause a read attempt past EOF if a delimited
character input value was at the end of a record.
It turns out that delimited list-directed (and NAMELIST) character
output is required to emit contiguous doubled instances of the
delimiter character when it appears in the output value. When
fixed-size records are being emitted, as is the case with internal
output, this is not possible when the problematic character falls
on the last position of a record. No two other Fortran compilers
do the same thing in this situation so there is no good precedent
to follow.
Because it seems least wrong, with this patch we now emit one copy
of the delimiter as the last character of the current record and
another as the first character of the next record. (The
second-least-wrong alternative might be to flag a runtime error,
but that seems harsh since it's not an explicit error in the standard,
and the output may not have to be usable later as input anyway.)
Consequently, the output is not suitable for use as list-directed or
NAMELIST input.
If a later standard were to clarify this case, this behavior will of
course change as needed to conform.
Differential Revision: https://reviews.llvm.org/D106695
NAMELIST I/O formatting uses the runtime infrastructure for
list-directed I/O. List-directed input processing has same state
that requires reinitialization for each successive NAMELIST input
item. This patch fixes bugs with "null" items and repetition counts
on NAMELIST input items after the first in the group.
Differential Revision: https://reviews.llvm.org/D106694
This change fixes a bug in the runtime portion of the CSHIFT intrinsic
that happens when the value of the SHIFT argument is negative.
Differential Revision: https://reviews.llvm.org/D106292
I'd previously merged this into the fir-dev branch. This change is to
do the same thing to the main branch of llvm-project.
Differential Revision: https://reviews.llvm.org/D106294
A field in DescriptorAddendum became unused during a recent
change but was not removed from the definition; it now elicits
a legitimate warning that's affecting some buildbots. Remove it.
F18 was sigalling an end-of-file error condition when reading an
unformatted sequential input file without an ultimate newline
(or CR-LF). Other Fortran implementations can handle it, so change
the runtime to support it.
Differential Revision: https://reviews.llvm.org/D106321
Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
A rank-0 static descriptor needs to be a vector; it's for
"v-list" values in defined derived type formatted I/O.
(Pushed without pre-review due to high confidence and an
unwell buildbot.)
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
The following semantic check is removed in OpenMP Version 5.0:
```
Taskloop simd construct restrictions: No reduction clause can be specified.
```
Also fix several typos.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D105874
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
Name resolution is always creating symbols with HostAssocDetails
for host variable names inside internal procedures. This helps lowering
identifying and dealing with such variables inside internal procedures.
However, the case where the variable appears in an ArrayRef mis-parsed
as a FunctionRef goes through a different name resolution path that did
not create such HostAssocDetails when needed. Pointer assignment RHS
are also skipping this path.
Add the logic to create HostAssocDetails for host symbols inisde internal
procedures that appear in mis-parsed ArrayRef or in pointer assignment RHS.
Differential Revision: https://reviews.llvm.org/D105464
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
Asher Mancinelli