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
When -fimplicit-none-ext is passed, flang behaves as if "implicit
none(external)" was specified for all relevant constructs in Fortran
source file.
Note: implicit17.f90 was based on implicit07.f90 with `implicit
none(external)` removed and `-fimplicit-none-ext` added.
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>
Currently the use of REAL/COMPLEX(KIND=10) as a type or literal constant
suffix elicits an optional warning message only. This leads to compiler
internal errors during lowering when these types appear in code being
compiled to non-x86_64 targets. For better error messaging, make the use
of these types a hard error in semantics instead when they are not
supported by the target architecture.
Some errors aren't being caught, such as the case in the linked bug
where the PAD= argument to RESHAPE() didn't have the same declared type
as the ARRAY=; this led to a crash in lowering. Refine the "same type"
testing logic for intrinsic procedures, and add a better test.
Fixes https://github.com/llvm/llvm-project/issues/124976.
When harvesting and formatting symbols USE'd from other modules, don't
emit USE statements to module files for names unless they come from the
topmost scope of the module. There was a check to prevent names from
derived type scopes from escaping in this way, but it must be made more
general to prevent other cases like dummy arguments in interfaces.
Fixes https://github.com/llvm/llvm-project/issues/124716.
A USE statement within a submodule (possibly in a nested scope) is not
allowed to USE the submodule's ancestor module directly, but it is
permissible to USE that ancestor module indirectly via another unrelated
module. Don't emit "already present in scope" errors for this case.
Fixes https://github.com/llvm/llvm-project/issues/124731.
When a separate module procedure is defined with MODULE PROCEDURE, the
compiler crashes if there is a dummy procedure in the interface defined
with only a result type. This is due to the type already having been
defined on the ProcEntityDetails symbol as part of earlier wholesale
symbol duplication. Adjust the code to not define the result type of the
ProcEntityDetails if it is already present, but to verify that it is the
same type instead.
Fixes https://github.com/llvm/llvm-project/issues/124487.
This patch implements support for the UNROLL directive to control how
many times a loop should be unrolled.
It must be placed immediately before a `DO LOOP` and applies only to the
loop that follows. N is an integer that specifying the unrolling factor.
This is done by adding an attribute to the branch into the loop in LLVM
to indicate that the loop should unrolled.
The code pushed to support the directive `VECTOR ALWAYS` has been
modified to take account of the fact that several directives can be used
before a `DO LOOP`.
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.
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed reference to local
coarray data as an actual argument, don't add the corank of the actual
argument to those characteristics.
Also clean up the TypeAndShape characteristics class a little; the
Attr::Coarray is redundant since the corank() accessor can be used to
the same effect.
A complex literal constant can have one BOZ component, since the type
and value of the literal can be determined by converting the BOZ value
to the type of the other component. But a complex literal constant with
two BOZ components doesn't have a well-defined type. The error message
was confusing in the case; emit a better one.
Fixes https://github.com/llvm/llvm-project/issues/124201.
When an allocatable or pointer was being associated as a storage
sequence with a dummy argument, the checks were using the actual storage
size of the allocatable or pointer's descriptor, not the size of the
storage that it references.
Fixes https://github.com/llvm/llvm-project/issues/123807.
The compiler was interpreting 'Q' as an exponent letter in a literal
real constant as meaning real(kind=10) on x86-64, which is the legacy
80387 80-bit extended precision floating-point type. It turns out that
'Q' means kind=16 with all other compilers, even for x86-64 targets.
Change to conform.
An assertion in module file generation didn't allow for a case that has
arisen in a test; remove it, extend commentary, and add a regression
test.
Fixes https://github.com/llvm/llvm-project/issues/123534.
Catch and report multiple initializations of the same procedure pointer
rather than assuming that control wouldn't reach a given point in name
resolution in that case.
Fixes https://github.com/llvm/llvm-project/issues/123538.
The check for a coarray actual argument being passed to a procedure with
an implicit interface was incorrect, yielding false positives for
coindexed objects. Fix.
It is valid to jump to a CHANGE TEAM statement from anywhere in the
containing executable part, and valid to jump to an END TEAM statement
from within the construct.
The event variable in an EVENT POST/WAIT statement can be a coarray
reference, and need not be an entire coarray.
Variables and potential subobject components with EVENT_TYPE/LOCK_TYPE
must be coarrays, unless they are potential subobjects nested within
coarrays or pointers.
This one appears to have been omitted when other ATOMIC_xxx intrinsic
procedures were defined. There's already tests for it, but they
apparently work even when ATOMIC_ADD must be interpreted as an external
procedure with an implicit interface. Extend the tests with INTRINSIC
NONE(EXTERNAL, TYPE) statements to ensure that they require the
intrinsic interpretation.
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>
With these changes, CUF atomic operations are handled as cudadevice
intrinsics and are converted straight to the LLVM dialect with the
`llvm.atomicrw` operation.
I am only submitting changes for `atomicadd` to gather feedback. If we
are to proceed with these changes I will add support for all other
applicable atomic operations following this pattern.
Whilst a little contrived, OpenMP allows you to utilise declare target
in the scope of one function to mark another function declare target,
currently this leads to a semantic error.
This appears to be because when we process the declare target directive
in the scope of another function (referring to another function), we do
not search externally from that functions scope to find possible prior
definitions, we only search in the current scope, this leads to us
implicitly defining a new variable and using that when implicit none is
not specified and then error'ng out or error'ng out earlier when implict
none is defined. This patch tries to address this behaviour by looking
externally for a function first and using that, before defaulting back
to the prior behaviour.
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.
Instead of "Cannot read ...", distinguish true errors in finding and
parsing module files from problems with unexpected hash codes by using
"Cannot parse" or "Cannot use" wording as appropriate.
A module can't USE itself, either directly within the top-level module
or from one of its submodules. Add a test for this case (which we
already caught), and improve the diagnostic for the more confusing case
involving a submodule.
Add tests for negative array extents where necessary, motivated by a
compiler crash exposed by yet another fuzzer test, and improve overall
error message quality for RESHAPE().
Fixes https://github.com/llvm/llvm-project/issues/122060.
