Some directive names can be used as clauses, for example in "cancel". In
case where a directive name is misplaced, it could be interpreted as a
clause.
Verify that such uses are valid, and emit a diagnostic message if not.
Fixes https://github.com/llvm/llvm-project/issues/138224
If a symbol is not declared, check-omp-structure hits an assert. It
should be safe to treat undeclared symbols as "not from a block", as
they would have to be declared to be in a block...
Adding simple test to confirm it gives error messages, not crashing.
This should fix issue #131655 (there is already a check for symbol being
not null in the code identified in the ticket).
Fixes:
- Add semantic checks along with the tests
- Move the detach clause to allowedOnceClauses list in Task construct
Restrictions:\
OpenMP 5.0: Task construct
- At most one detach clause can appear on the directive.
- If a detach clause appears on the directive, then a mergeable clause
cannot appear on the same directive.
OpenMP 5.2: Detach contruct
- If a detach clause appears on a directive, then the encountering task
must not be a final task.
- A variable that appears in a detach clause cannot appear as a list
item on a data-environment attribute clause on the same construct.
- A variable that is part of another variable (as an array element or a
structure element) cannot appear in a detach clause.
- event-handle must not have the POINTER attribute.
Support is added for parsing. Basic semantics support is added to
forward the code to Lowering. Lowering will emit a TODO error. Detailed
semantics checks and lowering is further work.
The UPDATE clause can be specified on both ATOMIC and DEPOBJ directives.
Currently, the ATOMIC directive has its own handling of it, and the
definition of the UPDATE clause only supports its use in the DEPOBJ
directive, where it takes a dependence-type as an argument.
The UPDATE clause on the ATOMIC directive may not have any arguments.
Since the implementation of the ATOMIC construct will be modified to use
the standard handling of clauses, the definition of UPDATE should
reflect that.
Add following semantic checks for ALLOCATE directive as per OpenMP 6.0
standard.
- List item in ALLOCATE directive must not be a dummy argument
- List item in ALLOCATE directive must not have POINTER attribute
- List item in ALLOCATE directive must not be a associate name
The OmpAtomicClause is a variant of a few specific clauses that are used
on the ATOMIC construct. The HINT clause, however, was represented as a
generic OmpClause, which somewhat complicated the analysis of an
OmpAtomicClause.
Introduce OmpHintClause to represent the contents of the HINT clause,
and use it on OmpAtomicClause similarly to how OmpFailClause is used.
NOWAIT was a tricky one because the clause can be on either the start or
the end directive. I couldn't find a convenient way to access the end
directive from the CANCEL directive nested inside of the construct, but
there are convenient ways to access the start directive. I have added a
list to the start directive context containing the clauses from the end
directive.
I'm not sure why strides were not allowed in array sections: the stride
is explicitly allowed by the standard from the first version where array
sections were introduced. The limitation is that the stride must not be
negative.
Here I have added the check for a negative stride and updated the test
for a zero length section to take account of the stride.
The `OmpDirectiveSpecification` contains directive name, the list of
arguments, and the list of clauses. It was introduced to store the
directive specification in METADIRECTIVE, and could be reused everywhere
a directive representation is needed.
In the long term this would unify the handling of common directive
properties, as well as creating actual constructs from METADIRECTIVE by
linking the contained directive specification with any associated user
code.
Adds Parser and Semantic Support for the below construct and clauses:
- Interop Construct
- Init Clause
- Use Clause
Note:
The other clauses supported by Interop Construct such as Destroy, Use,
Depend and Device are added already.
Below semantic checks for Taskloop clause mentioned in OpenMP [5.2]
specification were missing, this patch contains the semantic checks,
corresponding error messages and test cases:
OpenMP standard [5.2]:
[12.6] Taskloop Construct
[Restrictions]
Restrictions to the taskloop construct are as follows:
• The reduction-modifier must be default.
• The conditional lastprivate-modifier must not be specified.
Authored-by: shkaushi <sharang.kaushik@amd.com>
The cancellable construct names on CANCEL or CANCELLATION POINT
directives are actually clauses (with the same names as the
corresponding constructs).
Instead of parsing them into a custom structure, parse them as a clause,
which will make CANCEL/CANCELLATION POINT follow the same uniform scheme
as other constructs (<directive> [(<arguments>)] [clauses]).
Issue:
- Single construct used to throw a semantic error for copyprivate and
nowait clause when used in the single directive.
- Also, the copyprivate with nowait restriction has been removed from
OpenMP 6.0
Fix:
- Allow copyprivate and nowait on both single and end single directive
- Allow at most one nowait clause
- Throw a warning when the same list item is used in the copyprivate clause
on the end single directive
From Reference guide (OpenMP 5.2, 2.10.2):
```
!$omp single [clause[ [,]clause] ... ]
loosely-structured-block
!$omp end single [end-clause[ [,]end-clause] ...]
clause:
copyprivate (list)
nowait
[...]
end-clause:
copyprivate (list)
nowait
```
Towards: https://github.com/llvm/llvm-project/issues/110008
Then use this in the Flang compiler for parsing the OpenMP declare
reduction.
This has no real functional change to the existing code, it's only
moving the declaration itself around.
A few tests has been updated, to reflect the new type names.
The syntax with the object list following the memory-order clause has
been removed in OpenMP 5.2. Still, accept that syntax with versions >=
5.2, but treat it as deprecated (and emit a warning).
Extend semantic checks for `omp loop` directive to report errors when a
`reduction` clause is specified on a standalone `loop` directive with
`teams` binding.
This is similar to how clang behaves.
Enough suport to parse correctly formed directives of !$OMP ASSUME and
!$OMP ASSUMES with teh related clauses that go with them: ABSENT,
CONTAINS, NO_OPENPP, NO_OPENMP_ROUTINES, NO_PARALLELISM and HOLDS.
Tests added for unparsing and dump parse-tree.
Semantics support is very minimal and no specific tests added.
The lowering will hit a TODO, and there are tests in Lower/OpenMP/Todo
to make it clear that this is currently expected behaviour.
---------
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>
Part of the DECLARE REDUCTION was already supported by the parser, but
the semantics to add the reduction identifier wasn't implemented.
The semantics would not accept the name given by the reduction, so a few
lines added to support that.
Some tests were in place but not quite working, so fixed those up too.
Adding new tests for unparsing and parse-tree, as well as checking the
symbolic name being generated.
Lowering of DECLARE REDUCTION is not supported in this patch, and a test
that it hits the relevant TODO is in this patch (most of this was
already existing, but not actually testing the TODO message).
This patch introduces a directive set for combined constructs where
`teams` is the last leaf. This is used in a couple places to simplify
checks, which is NFC, but it also replaces two incorrect uses of
`topTeamsSet`.
Before, these checks would incorrectly skip combined constructs where
`teams` was the last leaf construct when checking for allowed nested
constructs inside of a `teams` region. Similarly, it would also
incorrectly perform these checks whenever a compound `teams` construct
where `teams` was the first leaf construct was found.
Before this patch, reduction of derived type components crashed the
compiler when trying to create the omp.declare_reduction.
In OpenMP 3.1 the standard says "a list item that appears in a reduction
clause must be a named variable of intrinsic type" (page 106). As I
understand it, a derived type component is not a variable.
OpenMP 4.0 added declare reduction, partly so that users could define
their own reductions on derived types. The above wording was removed
from the standard but derived type components were never explicitly
allowed.
OpenMP 5.0 added "A variable that is part of another variable, with the
exception of array elements, cannot appear in17 a reduction clause".
All standard versions also require the reduction argument to be
"definable", which roughly means that it is a variable. A
derived type component is more like an expression.
Fixes#125445
Implement parsing and symbol resolution for directives that take
arguments. There are a few, and most of them take objects. Special
handling is needed for two that take more specialized arguments: DECLARE
MAPPER and DECLARE REDUCTION.
This only affects directives in METADIRECTIVE's WHEN and OTHERWISE
clauses. Parsing and semantic checks of other cases is unaffected.
This implements checks of the validity of context set selectors and
trait selectors, plus the types of trait properties. Clause properties
are also validated, but not name or extension properties.
---------
Co-authored-by: Tom Eccles <tom.eccles@arm.com>
Parse METADIRECTIVE as a standalone executable directive at the moment.
This will allow testing the parser code.
There is no lowering, not even clause conversion yet. There is also no
verification of the allowed values for trait sets, trait properties.
Follow-up PR to fix the failure caused here:
https://github.com/llvm/llvm-project/pull/121028
Failure:
https://lab.llvm.org/buildbot/#/builders/89/builds/14474
Problems:
- Cray pointee cannot be used in the DSA list (If used results in segmentation fault)
- Cray pointer has to be in the DSA list when Cray pointee is used in the default (none) region
Fix: Added required semantic checks along the tests
Reference from the documentation (OpenMP 5.0: 2.19.1):
- Cray pointees have the same data-sharing attribute as the storage with
which their Cray pointers are associated.
This allows the Flang parser to accept the !$OMP DISPATCH and related
clauses.
Lowering is currently not implemented. Tests for unparse and parse-tree
dump is provided, and one for checking that the lowering ends in a "not
yet implemented"
---------
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Implementation details:
The UNTIED clause is recognized by setting the flag=0 for the default
case or performing logical OR to flag if other clauses are specified,
and this flag is passed as an argument to the `__kmpc_omp_task_alloc`
runtime call.
Resubmitting the PR with fix for the failure, as it was reverted here:
927a70daf31b1610627f346b0dc140eda72144b9
and previously merged here: https://github.com/llvm/llvm-project/pull/115283
Problems:
- Cray pointee cannot be used in the DSA list (If used results in
segmentation fault)
- Cray pointer has to be in the DSA list when Cray pointee is used in
the default (none) region
Fix: Added required semantic checks along the tests
Reference from the documentation (OpenMP 5.0: 2.19.1):
- Cray pointees have the same data-sharing attribute as the storage with
which their Cray pointers are associated.
This is trivially additional support for the existing ALLOCATE
directive, which allows an ALIGN clause.
The ALLOCATE directive is currently not implemented, so this is just
addding the necessary parser parts to allow the compiler to not say
"Huh? I don't get this" [or "Expected OpenMP construct"] when it
encounters the ALIGN clause.
Some parser testing is updated and a new todo test, just in case the
feature of align clause is not supported by the initial support for
ALLOCATE.
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.
