The header semantics.h is added implitly in the precompiled headers, but
the build was failing when precompiled headers are disabled (e.g.
using CMAKE_DISABLE_PRECOMPILE_HEADERS=ON):
```
../_src/flang/lib/Semantics/canonicalize-omp.cpp: In constructor ‘Fortran::semantics::CanonicalizationOfOmp::CanonicalizationOfOmp(Fortran::semantics::SemanticsContext&)’:
../_src/flang/lib/Semantics/canonicalize-omp.cpp:31:38: error: invalid use of incomplete type ‘class Fortran::semantics::SemanticsContext’
31 | : context_{context}, messages_{context.messages()} {}
| ^~~~~~~
In file included from ../_src/flang/lib/Semantics/canonicalize-omp.cpp:9:
../_src/flang/lib/Semantics/canonicalize-omp.h:17:7: note: forward declaration of ‘class Fortran::semantics::SemanticsContext’
17 | class SemanticsContext;
| ^~~~~~~~~~~~~~~~
compilation terminated due to -fmax-errors=1.
```
OpenMP 6.0 has changed the modifiers on the MAP clause. Previous patch
has introduced parsing support for them. This patch introduces
processing of the new forms in semantic checks and in lowering. This
only applies to existing modifiers, which were updated in the 6.0 spec.
Any of the newly introduced modifiers (SELF and REF) are ignored.
OpenMP 6.0 has changed the modifiers on the MAP clause:
- map-type-modifier has been split into individual modifiers,
- map-type "delete" has become a modifier,
- new modifiers have been added.
This patch adds parsing support for all of the OpenMP 6.0 modifiers. The
old "map-type-modifier" is retained, but is no longer created in
parsing. It will remain to take advantage of the preexisting modifier
validation for older versions: when the OpenMP version is < 6.0, the
modifiers will be rewritten back as map-type-modifiers (or map- type in
case of "delete").
In this patch the modifiers will always be rewritten in the older format
to isolate these changes to parsing as much as possible.
As reported in #145917 and #147309, there are situation's where flang
may crash. This is because `nextIt` in
`RewriteOpenMPLoopConstruct` gets re-assigned when an iterator is erased
from the block. If this is missed, Flang may attempt to access a
location in memory that is not accessable and cause a compiler crash.
This adds protection where the crash can occur, and a test with a
reproducer that can trigger the crash.
Fixes#147309
In OpenMP Version 5.1, the tile and unroll directives were added. When
using these directives, it is possible to nest them within other OpenMP
Loop Constructs. This patch enables the semantics to allow for this
behaviour on these specific directives. Any nested loops will be stored
within the initial Loop Construct until reaching the DoConstruct itself.
Relevant tests have been added, and previous behaviour has been retained
with no changes.
See also, #110008
Allow utility constructs (error and nothing) to appear in the
specification part as well as the execution part. The exception is
"ERROR AT(EXECUTION)" which should only be in the execution part.
In case of ambiguity (the boundary between the specification and the
execution part), utility constructs will be parsed as belonging to the
specification part. In such cases move them to the execution part in the
OpenMP canonicalization code.
This fixes a compilation error when code like this is presented to the
compiler:
!$OMP PARALLEL DO
!DIR$ VECTOR ALIGNED
DO 20 i=1,N
a = a + 0.5
20 CONTINUE
The directive itself is later ignored (with a warning that this is
happening), but because the compiler already errored out before that
point, it completely fails to compile this code. Other compilers accept
the code without complaints.
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
This reverts commit 5faf45a3d24e603cbc8fe4eb45da386653dae5e5.
Once again arcanist stripped the co-author metadata. I'm going to add it to the revision description and try one last time.
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
