[flang] Fix parsing and semantics for array element substring%KIND/%LEN

A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mi

[flang] Fix parsing and semantics for array element substring%KIND/%LEN

A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.

Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.

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

show more ...

[flang][OpenMP] Added parser support for in_reduction clause

OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives.
This patch adds parser support for the same.

Reviewed By: kiranchandra

[flang][OpenMP] Added parser support for in_reduction clause

OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives.
This patch adds parser support for the same.

Reviewed By: kiranchandramohan

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

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

[flang] Handle parameter-dependent types in PDT initializers

For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyz

[flang] Handle parameter-dependent types in PDT initializers

For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,

type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type

To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.

This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.

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

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][Parser] Add a node for individual sections in sections construct

This patch adds parser nodes for each indivudual section in sections
construct. This should help with the translation to FIR.

[flang][Parser] Add a node for individual sections in sections construct

This patch adds parser nodes for each indivudual section in sections
construct. This should help with the translation to FIR. `!$omp section`
was not recognized as a construct and hence needed special handling.

`OpenMPSectionsConstruct` contains a list of `OpenMPConstruct`. Each
such `OpenMPConstruct` wraps an `OpenMPSectionConstruct`
(section, not sections). An `OpenMPSectionConstruct` is a wrapper around
a `Block`.

Reviewed By: kiranchandramohan, peixin

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

show more ...

[flang] Implement semantics for DEC STRUCTURE/RECORD

Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE.

[flang] Implement semantics for DEC STRUCTURE/RECORD

Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.

These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.

Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.

This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.

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

show more ...

Added OpenMP 5.0 specification based semantic checks for CRITICAL construct name resolution

As reported in https://bugs.llvm.org/show_bug.cgi?id=48145, name resolution for omp critical construct was

Added OpenMP 5.0 specification based semantic checks for CRITICAL construct name resolution

As reported in https://bugs.llvm.org/show_bug.cgi?id=48145, name resolution for omp critical construct was failing. This patch adds functionality to help that name resolution as well as implementation to catch name mismatches.

The following semantic restrictions are therefore handled here:

- If a name is specified on a critical directive, the same name must also be specified on the end critical directive

- If no name appears on the critical directive, no name can appear on the end critical directive

- If a name appears on either the start critical directive or the end critical directive

Reviewed By: kiranchandramohan

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

show more ...

[flang] Save AllocateObject and PointerObject analyzed expression

`parser::AllocateObject` and `parser::PointerObject` can be represented
as typed expressions once analyzed. This simplifies the work

[flang] Save AllocateObject and PointerObject analyzed expression

`parser::AllocateObject` and `parser::PointerObject` can be represented
as typed expressions once analyzed. This simplifies the work for parse-tree
consumers that work with typed expressions to deal with allocatable and
pointer objects such as lowering.

This change also makes it easier to add typedExpr in the future by
automatically handling nodes that have this member when possible.

Changes:

- Add a `mutable TypedExpr typedExpr` field to `parser::PointerObject` and `parser::AllocateObject`.
- Add a `parser::HasTypedExpr<T>` helper to better share code relating to typedExpr in the parse tree.
- Add hooks in `semantics::ExprChecker` for AllocateObject and PointerObject nodes, and use
ExprOrVariable on it to analyze and set the tyedExpr field during
expression analysis. This required adding overloads for `AssumedTypeDummy`.
- Update check-nullify.cpp and check-deallocate.cpp to not re-analyze the StructureComponent but to
use the typedExpr field instead.
- Update dump/unparse to use HasTypedExpr and use the typedExpr when there is one.

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

show more ...

[flang][directive] Get rid of flangClassValue in TableGen

The TableGen emitter for directives has two slots for flangClass information and this was mainly
to be able to keep up with the legacy openm

[flang][directive] Get rid of flangClassValue in TableGen

The TableGen emitter for directives has two slots for flangClass information and this was mainly
to be able to keep up with the legacy openmp parser at the time. Now that all clauses are encapsulated in
AccClause or OmpClause, these two strings are not necessary anymore and were the the source of couple
of problem while working with the generic structure checker for OpenMP.
This patch remove the flangClassValue string from DirectiveBase.td and use the string flangClass as the
placeholder for the encapsulated class.

Reviewed By: sameeranjoshi

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

show more ...

[openacc] Rename generated file from ACC.cpp.inc to ACC.inc to match D92955

This patch rename the tablegen generated file ACC.cpp.inc to ACC.inc in order
to match what was done in D92955. This file

[openacc] Rename generated file from ACC.cpp.inc to ACC.inc to match D92955

This patch rename the tablegen generated file ACC.cpp.inc to ACC.inc in order
to match what was done in D92955. This file is included in header file as well as .cpp
file so it make more sense.

Reviewed By: sameeranjoshi

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

show more ...

[flang][openmp] Make Reduction clause part of OmpClause

After discussion in D93105 we found that the reduction clause was not following
the common OmpClause convention. This patch makes reduction cl

[flang][openmp] Make Reduction clause part of OmpClause

After discussion in D93105 we found that the reduction clause was not following
the common OmpClause convention. This patch makes reduction clause part of OmpClause
with a value of OmpReductionClause in a similar way than task_reduction.
The unparse function for OmpReductionClause is adapted since the keyword and parenthesis
are issued by the corresponding unparse function for parser::OmpClause::Reduction.

Reviewed By: sameeranjoshi

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

show more ...

[Flang][openmp][5.0] Add task_reduction clause.

See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This

[Flang][openmp][5.0] Add task_reduction clause.

See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.

Reviewed By: clementval

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

Co-authored-by: Valentin Clement <[email protected]>

show more ...

Revert "[Flang][openmp][5.0] Add task_reduction clause."

This reverts commit 9a7895dc20852b662a66976d06871ec2a0b968c8.
Reverting due to missing Co-author attribution.

https://reviews.llvm.org/D93105

[Flang][openmp][5.0] Add task_reduction clause.

See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This

[Flang][openmp][5.0] Add task_reduction clause.

See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.

Reviewed By: clementval

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

show more ...

[Flang][openmp][5/5] Make dist_schedule clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits

[Flang][openmp][5/5] Make dist_schedule clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.

This patch makes `OmpDistScheduleClause` clause part of `OmpClause`.
The unparse function for `OmpDistScheduleClause` is adapted since the keyword
and parenthesis are issued by the corresponding unparse function for
`parser::OmpClause::DistSchedule`.

Reviewed By: clementval, kiranktp

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

show more ...

[Flang][openmp][4/5] Make nowait clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of usin

[Flang][openmp][4/5] Make nowait clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.

This patch makes `OmpNoWait` clause part of `OmpClause`.

Reviewed By: clementval, kiranktp

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

show more ...

[Flang][openmp][3/5] Make ProcBind clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of us

[Flang][openmp][3/5] Make ProcBind clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.

This patch makes `OmpProcBindClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpProcBindClause`.

Reviewed By: clementval, kiranktp

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

show more ...

[Flang][openmp][2/5] Make Default clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of usi

[Flang][openmp][2/5] Make Default clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.

This patch makes `OmpDefaultClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpDefaultClause`.

Reviewed By: clementval, kiranktp

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

show more ...

[Flang][openmp][1/5] Make Allocate clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of us

[Flang][openmp][1/5] Make Allocate clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.

This patch makes `allocate` clause part of `OmpClause`.The unparse function for
`OmpAllocateClause` is adapted since the keyword and parenthesis are issued by
the corresponding unparse function for `parser::OmpClause::Allocate`.

Reviewed By: clementval

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

show more ...

[openacc] Use TableGen enum for default clause value

Use the TableGen feature to have enum values for clauses.
Next step will be to extend the MLIR part used currently by OpenMP
to use the same enum

[openacc] Use TableGen enum for default clause value

Use the TableGen feature to have enum values for clauses.
Next step will be to extend the MLIR part used currently by OpenMP
to use the same enum on the dialect side.

This patch also add function that convert the enum to StringRef to be
used on the dump-parse-tree from flang.

Reviewed By: jdoerfert

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

show more ...

[openmp] Remove clause from OMPKinds.def and use OMP.td info

Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single s

[openmp] Remove clause from OMPKinds.def and use OMP.td info

Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single source of truth for the
directives and clauses.

To avoid generate lots of specific small code from tablegen, the macros previously
used in OMPKinds.def are generated almost as identical. This can be polished and
possibly removed in a further patch.

Reviewed By: jdoerfert

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

show more ...

[flang][openacc] Enforce restriction on routine directive and clauses

This patch add some checks for the restriction on the routine directive
and fix several issue at the same time.

Validity tests

[flang][openacc] Enforce restriction on routine directive and clauses

This patch add some checks for the restriction on the routine directive
and fix several issue at the same time.

Validity tests have been added in a separate file than acc-clause-validity.f90 since this one
became quite large. I plan to split the larger file once on-going review are done.

Reviewed By: sameeranjoshi

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

show more ...

[Flang][OpenMP-5.0] Semantic checks for flush construct.

From OMP 5.0 [2.17.8]
Restriction:
If memory-order-clause is release,acquire, or acq_rel, list items must not be specified on the flush direc

[Flang][OpenMP-5.0] Semantic checks for flush construct.

From OMP 5.0 [2.17.8]
Restriction:
If memory-order-clause is release,acquire, or acq_rel, list items must not be specified on the flush directive.

Reviewed By: kiranchandramohan, clementval

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

show more ...