[flang][OpenMP] Rework LINEAR clause (#119278)

The OmpLinearClause class was a variant of two classes, one for when the
linear modifier was present, and one for when it was absent. These two
class

[flang][OpenMP] Rework LINEAR clause (#119278)

The OmpLinearClause class was a variant of two classes, one for when the
linear modifier was present, and one for when it was absent. These two
classes did not follow the conventions for parse tree nodes, (i.e.
tuple/wrapper/union formats), which necessitated specialization of the
parse tree visitor.

The new form of OmpLinearClause is the standard tuple with a list of
modifiers and an object list. The specialization of parse tree visitor
for it has been removed.
Parsing and unparsing of the new form bears additional complexity due to
syntactical differences between OpenMP 5.2 and prior versions: in OpenMP
5.2 the argument list is post-modified, while in the prior versions, the
step modifier was a post-modifier while the linear modifier had an
unusual syntax of `modifier(list)`.

With this change the LINEAR clause is no different from any other
clauses in terms of its structure and use of modifiers. Modifier
validation and all other checks work the same as with other clauses.

show more ...

[flang][OpenMP] Use new modifiers in IF/LASTPRIVATE (#118128)

The usual changes, added more references to OpenMP specs.

[flang][OpenMP] Use new modifiers in DEPEND/GRAINSIZE/NUM_TASKS (#117917)

The usual changes, added more references to OpenMP specs.

[flang][OpenMP] Use new modifiers with AFFINITY/ALIGNED/DEVICE (#117786)

This is a mostly mechanical change from specific modifiers embedded
directly in a clause to the Modifier variant.

Additio

[flang][OpenMP] Use new modifiers with AFFINITY/ALIGNED/DEVICE (#117786)

This is a mostly mechanical change from specific modifiers embedded
directly in a clause to the Modifier variant.

Additional comments and references to the OpenMP specs were added.

show more ...

[flang][OpenMP] Rename some `Type` members in OpenMP clauses (#117784)

The intent is to keep names in sync with the terminology from the OpenMP
spec:
```
OmpBindClause::Type -> Binding

[flang][OpenMP] Rename some `Type` members in OpenMP clauses (#117784)

The intent is to keep names in sync with the terminology from the OpenMP
spec:
```
OmpBindClause::Type -> Binding
OmpDefaultClause::Type -> DataSharingAttribute
OmpDeviceTypeClause::Type -> DeviceTypeDescription
OmpProcBindClause::Type -> AffinityPolicy
```
Add more comments with references to the OpenMP specs.

show more ...

[flang][OpenMP] Use new modifiers in ALLOCATE clause (#117627)

Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative

[flang][OpenMP] Use new modifiers in ALLOCATE clause (#117627)

Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative
message, and to highlight the modifier itsef, not the whole clause.
Remove the checks for the allocator expression itself being positive:
there is nothing in the spec that says that it should be positive.

Remove the "simple" modifier from the AllocateT template, since both
simple and complex modifiers are the same thing, only differing in
syntax.

show more ...

[flang][OpenMP] Use new modifier infrastructure for MAP/FROM/TO clauses (#117447)

This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, an

[flang][OpenMP] Use new modifier infrastructure for MAP/FROM/TO clauses (#117447)

This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, and MotionModifiers. Map
and the motion clauses are now handled in the same way as all other
clauses with modifiers, with one exception: the commas separating their
modifiers are optional. This syntax is deprecated in OpenMP 5.2.

Implement version checks for modifiers: for a given modifier on a given
clause, check if that modifier is allowed on this clause in the
specified OpenMP version. This replaced several individual checks.

Add a testcase for handling map modifiers in a different order, and for
diagnosing an ultimate modifier out of position.

show more ...

[flang][OpenMP] Use new modifier code in ORDER and SCHEDULE clauses (#117081)

This actually simplifies the AST node for the schedule clause: the two
allowed modifiers can be easily classified as th

[flang][OpenMP] Use new modifier code in ORDER and SCHEDULE clauses (#117081)

This actually simplifies the AST node for the schedule clause: the two
allowed modifiers can be easily classified as the ordering-modifier and
the chunk-modifier during parsing without the need to create additional
classes.

show more ...

[flang][OpenMP] Apply modifier representation to semantic checks (#116658)

Also, define helper macros in parse-tree.h.

Apply the new modifier representation to the DEFAULTMAP and REDUCTION
claus

[flang][OpenMP] Apply modifier representation to semantic checks (#116658)

Also, define helper macros in parse-tree.h.

Apply the new modifier representation to the DEFAULTMAP and REDUCTION
clauses, with testcases utilizing the new modifier validation.

OpenMP modifier overhaul: #3/3

show more ...

[flang][OpenMP] Normalize clause modifiers that exist on their own (#116655)

This is the first part of the effort to make parsing of clause modifiers
more uniform and robust. Currently, when multip

[flang][OpenMP] Normalize clause modifiers that exist on their own (#116655)

This is the first part of the effort to make parsing of clause modifiers
more uniform and robust. Currently, when multiple modifiers are allowed,
the parser will expect them to appear in a hard-coded order.
Additionally, modifier properties (such as "ultimate") are checked
separately for each case.

The overall plan is
1. Extract all modifiers into their own top-level classes, and then
equip them with sets of common properties that will allow performing the
property checks generically, without refering to the specific kind of
the modifier.
2. Define a parser (as a separate class) for each modifier.
3. For each clause define a union (std::variant) of all allowable
modifiers, and parse the modifiers as a list of these unions.

The intent is also to isolate parts of the code that could eventually be
auto-generated.

OpenMP modifier overhaul: #1/3

show more ...

[flang][OpenMP] Parse DOACROSS clause (#115396)

Extract the SINK/SOURCE parse tree elements into a separate class
`OmpDoacross`, share them between DEPEND and DOACROSS clauses. Most of
the changes

[flang][OpenMP] Parse DOACROSS clause (#115396)

Extract the SINK/SOURCE parse tree elements into a separate class
`OmpDoacross`, share them between DEPEND and DOACROSS clauses. Most of
the changes in Semantics are to accommodate the new contents of
OmpDependClause, and a mere introduction of OmpDoacrossClause.

There are no semantic checks specifically for DOACROSS.

show more ...

[flang][OpenMP] Update handling of DEPEND clause (#113620)

Parse the locator list in OmpDependClause as an OmpObjectList (instead
of a list of Designators). When a common block appears in the locat

[flang][OpenMP] Update handling of DEPEND clause (#113620)

Parse the locator list in OmpDependClause as an OmpObjectList (instead
of a list of Designators). When a common block appears in the locator
list, show an informative message.
Implement resolving symbols in DependSinkVec in a dedicated visitor
instead of having a visitor for OmpDependClause.
Resolve unresolved names common blocks in OmpObjectList.

Minor changes to the code organization:
- rename OmpDependenceType to OmpTaskDependenceType (to follow 5.2
terminology),
- rename Depend::WithLocators to Depend::DepType,
- add comments with more detailed spec references to parse-tree.h.

---------

Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>

show more ...

[Flang][OpenMP] Add parser support for grainsize and num_tasks clause (#113136)

These clauses are applicable only for the taskloop directive. Since the
directive has a TODO error, skipping the addi

[Flang][OpenMP] Add parser support for grainsize and num_tasks clause (#113136)

These clauses are applicable only for the taskloop directive. Since the
directive has a TODO error, skipping the addition of TODOs for these
clauses.

show more ...

[flang][OpenMP] Parsing support for map type modifiers (#111860)

This commit adds parsing of type modifiers for the MAP clause: CLOSE,
OMPX_HOLD, and PRESENT. The support for ALWAYS has already exi

[flang][OpenMP] Parsing support for map type modifiers (#111860)

This commit adds parsing of type modifiers for the MAP clause: CLOSE,
OMPX_HOLD, and PRESENT. The support for ALWAYS has already existed.

The new modifiers are not yet handled in lowering: when present, a TODO
message is emitted and compilation stops.

show more ...

[flang] Add parsing of DO CONCURRENT REDUCE clause (#92518)

Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parse

[flang] Add parsing of DO CONCURRENT REDUCE clause (#92518)

Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parser
in MLIR, the front end accepts both arbitrary operations and procedures
for the REDUCE clause. But later Semantics can notify type errors and
resolve procedure names.

show more ...

[flang] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are m

[flang] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are messages produced
by the parser and none of them are fatal, those messages are emitted to
the user before compilation continues with semantic analysis, and any
messages produced by semantics are emitted after the messages from
parsing.

This can be confusing for the user, as the messages may no longer all be
in source file location order. It also makes it difficult to write tests
that check for both non-fatal messages from parsing as well as messages
from semantics using inline CHECK: or other expected messages in test
source code.

This patch ensures that if semantic analysis is performed, and non-fatal
messages were produced by the parser, that all the messages will be
combined and emitted in source file order.

show more ...

[flang] Add notify-type and notify-wait-stmt (#76594)

Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` an

[flang] Add notify-type and notify-wait-stmt (#76594)

Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` and
`C1178`, from the Fortran 2023 standard. Add three semantics tests for
`notify-wait-stmt`.

show more ...

[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units

Re-land commit 3787fd942f3927345320cc97a479f13e44355805

This patch adds support for storing OpenMP REQUIRES in

[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units

Re-land commit 3787fd942f3927345320cc97a479f13e44355805

This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.

Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.

The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.

This is patch 3/5 of a series splitting D149337 to simplify review.

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

show more ...

Revert "[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units"

Changes in this commit make some gfortran tests crash the compiler. It is
likely trying to dereference

Revert "[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units"

Changes in this commit make some gfortran tests crash the compiler. It is
likely trying to dereference undefined symbol pointers.

This reverts commit 3787fd942f3927345320cc97a479f13e44355805.

show more ...

[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units

This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprogra

[Flang][OpenMP][Sema] Support propagation of REQUIRES information across program units

This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.

Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.

The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.

This is patch 3/5 of a series splitting D149337 to simplify review.

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

show more ...

[flang][openacc] Add parsing support for dim in gang clause

Add parsing supprot for dim in gang clause

Depends on D151971

Reviewed By: razvanlupusoru, jeanPerier

Differential Revision: https://re

[flang][openacc] Add parsing support for dim in gang clause

Add parsing supprot for dim in gang clause

Depends on D151971

Reviewed By: razvanlupusoru, jeanPerier

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

show more ...

[Flang] Syntax support for OMP Allocators Construct

OpenMP 5.2 introduces a Fortran specific construct that aims to replace the executable allocate directive. This patch seeks to add parser support

[Flang] Syntax support for OMP Allocators Construct

OpenMP 5.2 introduces a Fortran specific construct that aims to replace the executable allocate directive. This patch seeks to add parser support for the directive as well as the allocator clause with the [[ https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5-2.pdf#section.6.6 | extended align/complex ]] modifier.

Reviewed By: kiranchandramohan

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

show more ...

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

Updated to fix build issues.

Reviewed By: jdoerfert

Different

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

Updated to fix build issues.

Reviewed By: jdoerfert

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

show more ...

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

Updated to fix build issues.

Reviewed By: jdoerfert

Different

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

Updated to fix build issues.

Reviewed By: jdoerfert

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

show more ...

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

> One thing we need...is a way to determine what features a cod

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.

> One thing we need...is a way to determine what features a code uses. Preferably we would also be able to determine if they are implemented or not. Just the former could be done with a visitor for the parse tree. For the latter we would continue compilation and somehow ignore todo errors but collect them - @jdoerfert

Reviewed By: jdoerfert

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

show more ...