Fortran's syntax is ambiguous for some assignment statements (to array
elements or to the targets of pointers returned by functions) that
appear as the first executable statements in a subprogram or BLOCK
construct. Is A(I)=X a statement function definition at the end of the
specification part, or ar array element assignment statement, or an
assignment to a pointer returned by a function named A?
Since f18 builds a parse tree for the entire source file before
beginning any semantic analysis, we can't tell which is which until
after name resolution, at which point the symbol table has been built.
So we have to walk the parse tree and rewrite some misparsed statement
function definitions that really were assignment statements.
There's a bug in that code, though, due to the fact that the
implementation used state in the parse tree walker to hold a list of
misparsed statement function definitions extracted from one
specification part to be reinserted at the beginning of the next
execution part that is visited; it didn't work for misparsed cases BLOCK
constructs. Their parse tree nodes encapsulate a parser::Block, not an
instance of the wrapper class parser::ExecutionPart. So misparsed
statement functions in BLOCK constructs were being rewritten into
assignment statement that were inserted at the beginning of the
executable part of the following subprogram, if and wherever one
happened to occur. This led to crashes in lowering and much
astonishment.
A simple fix would have been to adjust the rewriting code to always
insert the list at the next visited parser::Block, since
parser::ExecutionPart is just a wrapper around Block anyway; but this
patch goes further to do the "right thing", which is a restructuring of
the rewrite that avoids the use of state and any assumptions about parse
tree walking visitation order.
Fixes https://github.com/llvm/llvm-project/issues/112549.
Nearly every Fortran compiler supports "PRINT namelistname" as a synonym
for "WRITE (*, NML=namelistname)". Implement this extension via parse
tree rewriting.
Fixes https://github.com/llvm/llvm-project/issues/111738.
This patch creates the `OmpRewriteMutator` pass that runs at the end of
`RewriteParseTree()`. This pass is intended to make OpenMP-specific mutations
to the PFT after name resolution.
In the case of the `atomic_default_mem_order` clause of the REQUIRES directive,
name resolution results in populating global symbols with information about the
REQUIRES clauses that apply to that scope. The new rewrite pass is then able to
use this information in order to explicitly set the memory order of ATOMIC
constructs for which that is not already specified.
Given that this rewrite happens before semantics checks, the check of the order
in which ATOMIC constructs without explicit memory order and REQUIRES
directives with `atomic_default_mem_order` appear is moved earlier into the
rewrite pass. Otherwise, these problems would not be caught by semantics
checks, since the PFT would be modified by that stage.
This is patch 4/5 of a series splitting D149337 to simplify review.
Depends on D157983.
Differential Revision: https://reviews.llvm.org/D158096
When an I/O statement's UNIT= specifier is a variable that is a
function reference, parse tree rewriting may determine the wrong type
of the result because generic resolution has not yet been performed.
So move this bit of parse tree rewriting into I/O semantic
checking so that the right handling (integer -> external file unit
number, character pointer -> internal I/O) applies.
Differential Revision: https://reviews.llvm.org/D135210
f18 was treating "f() = 1" as a statement function definition
if it could be viewed as being in the specification part and
"f" was a USE-associated function returning a data pointer.
(The non-USE-associated case is fine.) Fix to allow for "f"
to be USE associated.
Differential Revision: https://reviews.llvm.org/D127430
F(X)=Y may be initially parsed as a statement function definition; an
existing pass will detect statement functions that should be rewritten
into assignment statemets with array element references as their
left-hand side variables. However, F() may also be a reference to a
function that returns a data pointer, and f18 did not handle this
case correctly.
The right fix is to rewrite the parse tree for F(X)=Y into an assignment
to a function reference result. The cases that are actually assignments
to array elements -- including all of the cases previously handled --
will have their left-hand sides converted to array element references
later by another existing rewriting step.
Differential Revision: https://reviews.llvm.org/D124299
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.
Differential Revision: https://reviews.llvm.org/D93323
An io-unit that is an internal-file-variable is syntactically identical
to a file-unit-number expression that is a variable reference. An
ambiguous unit is initially parsed as an internal-file-variable. If
semantic analysis determines that the unit is not of character type,
it is rewritten as an internal-file-variable. This modification must
retain source coordinate information.
Differential revision: https://reviews.llvm.org/D91375
READ(CVAR)[,item-list] with a character variable CVAR
could be parsed as an unformatted READ from an internal
unit or as a formatted READ from the default external unit
with a needlessly parenthesized variable format. We parse
it as the former, but Fortran doesn't have unformatted
internal I/O.
Differential revision: https://reviews.llvm.org/D90493
Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing
via conversion to initializers.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82137
