[flang] Fix rewriting of misparsed statement functions (#112934)

Fortran's syntax is ambiguous for some assignment statements (to array
elements or to the targets of pointers returned by functions)

[flang] Fix rewriting of misparsed statement functions (#112934)

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.

show more ...

[flang] Support "PRINT namelistname" (#112024)

Nearly every Fortran compiler supports "PRINT namelistname" as a synonym
for "WRITE (*, NML=namelistname)". Implement this extension via parse
tree r

[flang] Support "PRINT namelistname" (#112024)

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.

show more ...

[Flang][OpenMP][Sema] Add directive rewrite pass to support atomic_default_mem_order REQUIRES clause

This patch creates the `OmpRewriteMutator` pass that runs at the end of
`RewriteParseTree()`. Thi

[Flang][OpenMP][Sema] Add directive rewrite pass to support atomic_default_mem_order REQUIRES clause

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

show more ...

[flang] Delay parse tree rewriting for I/O UNIT=func()

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 re

[flang] Delay parse tree rewriting for I/O UNIT=func()

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

show more ...

[flang] Handle USE association in parse tree rewriting

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-associ

[flang] Handle USE association in parse tree rewriting

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

show more ...

[flang] Disambiguate F(X)=Y case where F is a function returning a pointer

F(X)=Y may be initially parsed as a statement function definition; an
existing pass will detect statement functions that sh

[flang] Disambiguate F(X)=Y case where F is a function returning a pointer

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

show more ...

[flang] Add & use a better visit() (take 2)

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().

[flang] Add & use a better visit() (take 2)

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().

show more ...

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/build

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/builds/4346
* https://lab.llvm.org/buildbot/#/builders/180/builds/3803
* https://lab.llvm.org/buildbot/#/builders/175/builds/10419
* https://lab.llvm.org/buildbot/#/builders/191/builds/4318
* https://lab.llvm.org/buildbot/#/builders/173/builds/4274
* https://lab.llvm.org/buildbot/#/builders/181/builds/4297

All these bots failed with a time-out:
```
command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill
```
I'm guessing that that's due to template instantiations failing at some
point (https://reviews.llvm.org/D122441 introduced a custom
implementation of std::visit). Everything seems fine when either:
* building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12)
* building on AArch64 with GCC (tested with GCC 11)

show more ...

[flang] Add & use a better 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

[flang] Add & use a better 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

show more ...

[flang] Clean up TODO comments and fix one (DATA constant ambiguity)

Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in

[flang] Clean up TODO comments and fix one (DATA constant ambiguity)

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

show more ...

[flang] Include source information in an invalid file-unit-number message

An io-unit that is an internal-file-variable is syntactically identical
to a file-unit-number expression that is a variable

[flang] Include source information in an invalid file-unit-number message

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

show more ...

[flang] Detect and rewrite ambiguous READ(CVAR)[,item-list]

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

[flang] Detect and rewrite ambiguous READ(CVAR)[,item-list]

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

show more ...

[flang] DATA stmt processing (part 3/4): Remaining prep work

Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing

[flang] DATA stmt processing (part 3/4): Remaining prep work

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

show more ...

[flang] Process names in ASSIGN and assigned GOTO

Allow ASSIGNed integer variables as formats

Address review comment

Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d
Re

[flang] Process names in ASSIGN and assigned GOTO

Allow ASSIGNed integer variables as formats

Address review comment

Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d
Reviewed-on: https://github.com/flang-compiler/f18/pull/1099

show more ...

[flang] Reformat with latest clang-format and .clang-format

Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...