Issue deprecation warning for these directives.
Lowering currently supports parallel master, for all other combined or
composite directives involving master, issue TODO errors.
Note: The first commit changes the formatting and generalizes the
deprecation message emission for reuse in the second commit. I can pull
it out into a separate commit if required.
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>
Implement parsing of the AFFINITY clause on TASK construct, conversion
from the parser class to omp::Clause.
Lowering to HLFIR is unsupported, a TODO message is displayed.
Define `OmpIteratorSpecifier` and `OmpIteratorModifier` parser classes,
and add parsing for them. Those are reusable between any clauses that
use iterator modifiers.
Add support for iterator modifiers to the MAP clause up to lowering,
where a TODO message is emitted.
According to OpenMPv5.2 1.2.6, "For Fortran, a scalar variable with
intrinsic type, as defined by the base language, excluding character
type.". Likewise, section 4.3.1.3 states that atomic operations are on
"scalar variables of intrinsic type". This PR hence introduces a check
to error out when CHARACTER type is used in atomic operations.
Fixes https://github.com/llvm/llvm-project/issues/112918
Add missing semantic checks for the Workshare construct:
OpenMP 5.2: 11.4 Workshare Construct
- The construct must not contain any user-defined function calls unless
either the function is pure and elemental or the function call is
contained inside a parallel construct that is nested inside the
workshare construct. (Flang-new used to check only the elemental function,
but now it needs to be an impure elemental function)
- At most one NoWait clause can appear in the Workshare construct.
- Add tests for the same.
It is possible for the compiler to emit an impossible error message
about dummy argument character length incompatibility in the case of a
MODULE SUBROUTINE or FUNCTION defined later in a submodule with MODULE
PROCEDURE, when the character length is defined by USE association in
its interface. The checking for separate module procedure interface
compatibility needs to use a more flexible check than just operator== on
a semantics::ParamValue.
Nearly every Fortran compiler supports "PRINT namelistname" as a synonym
for "WRITE (*, NML=namelistname)". Implement this extension via parse
tree rewriting.
Fixes https://github.com/llvm/llvm-project/issues/111738.
Type interoperability warnings current issue for intrinsic types when
their type, kind, or length do not meet the requirements for C
interoperability. This turns out to be too noisy for the case of
one-byte characters with lengths other than one when creating C pointers
from C_LOC or C_F_POINTER -- it is not uncommon for programs to use
pointers to longer character objects.
So split the interoperability warning so that the case of a known bad
character length for an otherwise interoperable type is controlled by
its own UsageWarning enumerator, and leave that usage warning off by
default. This will better fit expectations in the default case while
still showing a warning under -pedantic.
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.
The original motivation came from this scenario:
```
!$omp parallel do shared(xyz)
xyz: do i = 1, 100
enddo xyz
!$omp end parallel do
```
Implement a general check for validity of items listed in OpenMP
clauses. In most cases they need to be variables, some clauses allow
"extended list items", i.e. variables or procedures.
Emit an error when an actual argument with potentially unknown size
(assumed size, or non-pointer non-allocatable assumed rank) with any
risk of needing initialization, finalization, or destruction is
associated with an INTENT(OUT) dummy argument with assumed rank.
Emit an optional portability warning for cases where the type is known
to be safe from needing initialization, finalization, or destruction,
since it's not conforming and might elicit an error from other
compilers.
Fixes https://github.com/llvm/llvm-project/issues/111120.
Fortran doesn't permit the use of a polymorphic I/O list item for
intrinsic data transfers, so the compiler emits an error message for
polymorphic items whose types can't possibly be handled by a defined I/O
subroutine. This check didn't allow for the possibility that the defined
I/O subroutine might apply to the parent component of an extended type.
Fixes https://github.com/llvm/llvm-project/issues/111021.
When a separate module procedure has a dummy procedure argument that is
simply declared EXTERNAL in its interface but is actually called as a
subroutine or function in its definition, the compiler is emitting an
error message. This is too strong; an error is appropriate only when the
dummy procedure in the definition has an interface that is incompatible
with the one in the interface definition.
However, this is not a safe coding practice, and can lead to trouble
during execution if a function is passed as an actual argument but
called as a subroutine in the procedure (or the other way around), so
add a warning message as well for this case (off by default).
Fixes https://github.com/llvm/llvm-project/issues/110797.
OpenMP prohibits privatisation of variables that appear in expressions
for statement functions.
This is a re-working of an old patch https://reviews.llvm.org/D93213 by
@praveen-g-ctt.
The old patch couldn't be landed because of ordering concerns. Statement
functions are rewritten during parse tree rewriting, but this was done
after resolve-directives and so some array expressions were incorrectly
identified as statement functions. For this reason **I have opted to
re-order the semantics driver so that resolve-directives is run after
parse tree rewriting**.
Closes#54677
---------
Co-authored-by: Praveen <praveen@compilertree.com>
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
This is allowed by the OpenMP and F23 standards. But variables in a
namelist are not allowed in OpenMP privatisation. I suspect this was an
oversight.
If we allow this we run into problems masking the original symbol with
the symbol for the reduction variable when the variable is accessed via
a namelist initialised as a global variable. See #101907. One solution
for this would be to force the namelist to always be initilized inside
of the block in which it is used (therefore using the correct mapping
for the reduction variable), but this could make some production
applications slow.
I tentatively think it is probably better to disallow a (perhaps
mistaken) edge case of the standards with (I think) little practical
use, than to make real applications slow in order to make this work. If
reviewers would rather keep to the letter of the standard, see #109303
which implements the alternative solution. I'm open to either path
forward.
Fixes#101907
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These are used in
some legacy codes such as libexodus.
All the above compilers accept using MALLOC and FREE with integers as
well, despite that this will often signify a bug in user code. We should
accept the same as the other compilers for compatibility.
When a format is missing a comma between two edit descriptors, the
previous token was an integer, and the following item is a repeatable
edit descriptor or a parenthesized group, we emit an error, since it
can't be known where the digits of the integer should be split. But in
the case of a single digit, the situation is not ambiguous, and the
message should be a warning.
Fixes https://github.com/llvm/llvm-project/issues/110261.
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
---------
Co-authored-by: Yi Wu <yi.wu2@arm.com>
If there is a clause that is allowed on a given directive in a later
version of the OpenMP spec, report an error and provide the minimal spec
version that allows the clause.
The case where a clause is not allowed on a directive at all is already
handled elsewhere.
This PR adds semantic checks to ensure the atomic capture construct
conforms to one of the valid forms:
[capture-stmt, update-stmt], [capture-stmt, write-stmt] or [update-stmt,
capture-stmt].
Functions checkForSymbolMatch and checkForSingleVariableOnRHS are moved
from flang/lib/Lower/DirectivesCommon.h to flang/Semantics/tools.h for
reuse.
---------
Co-authored-by: Kiran Chandramohan <kiranchandramohan@gmail.com>
A recent fix to the emission of derived type names to module files
exposed a regression in the case of a derived type that (1) has the same
name as a generic procedure interface and (2) has undergone renaming
through USE association before (3) being used in a declaration
significant to a module procedure interface. Fix.
For proper error detection of bad KIND= arguments, make IEEE_INT and
IEEE_REAL actual intrinsic functions. Lowering will have to check for
the new __builtin_ names.
The order of operations in name resolution wasn't converting named
entities to objects by the time that they were subjected to the implicit
typing rules in the case of interface blocks. This led to entities
remaining untyped without error, leading to a crash in module file
generation.
Fixes https://github.com/llvm/llvm-project/issues/108975.
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
The missing scope information led to a crash in OpenMP semantic checks
run before printing the error that was already discovered in the code.
The following block has to be skipped for this invalid code so that we
don't emit a second spurious error.
Fixes#82913
The associate name preserves the association with the selector
established in the associate statement. Therefore it is incorrect to
change the data-sharing attribute of the name.
Closes#58041
Emit a warning when an impure function is referenced from a DO
CONCURRENT or FORALL concurrent-header that is not nested within another
such construct. (That nested case is already an error.)
This patch removes from the list of allowed clauses for a handful of
compound constructs those that are specifically disallowed by the OpenMP
spec. In particular, the following restrictions are followed:
- (regarding combined constructs) If _directive-name-A_ is `target`, the
`copyin` clause must not be specified.
- (regarding composite constructs) If _directive-name-A_ is
`distribute`, the `ordered` clause must not be specified.
These restrictions are listed in the OpenMP Specification version 5.2,
sections 17.4 and 17.5. Since it's a similar case as PR #90754, I'm
adding people involved in that decision as reviewers here.
Mark the symbol with OmpShared, and then check that later in lowering to
avoid making a local loop index.
OpenMP 5.2 says: "Loop iteration variables of loops that are not associated
with any OpenMP directive maybe listed in data-sharing attribute clauses on
the surrounding teams, parallel or taskgenerating construct, and on enclosed
constructs, subject to other restrictions."
Tests updated to match the extra OmpShared attribute.
Add regression test for lowering to hlfir.
Closes#102961
---------
Co-authored-by: Tom Eccles <tom.eccles@arm.com>
An array that has one or more empty dimensions cannot have subscripts
unless there's a possibility that they constitute an empty array
section.
We previously only checked that constant subscripts are in bounds.
There's two entries in the intrinsic table for REAL; the first handles
the REAL(z) case of a COMPLEX argument, and the second handles the data
type/kind conversion case.
In the case of REAL(x,bad) with a bad or unsupported kind of REAL,
neither table entry was matching. In the event of an unrecognized
intrinsic function, the compiler emits the first error message that
resulted, which was confusing here because it was a complaint about
having too many arguments.
Reversing the order of the intrinsic table entries would fix the error
message, but would also have broken REAL(z) with a complex argument,
since it would then be treated as REAL(z,KIND=KIND(0.)) rather than
REAL(z,KIND=KIND(z)).
The fix is to let the second entry "hit" with improved error recovery.
It is a non-mandatory error to reference an external procedure via an
implicit interface declaration (EXTERNAL or PROCEDURE()) when the
external procedure has an interface that requires the presence of an
explicit interface to be called.
Until now, the compiler has issued a fatal error message from semantics
for this situation. But (1) there are situations, such as passing such
an EXTERNAL as an actual argument, or as the target of a procedure
pointer assignment, where little or no harm is done, (2) other compilers
don't/can't detect this error, even when the procedure's definition is
in the same source file, and (3) it shows up in some real applications.
So downgrade this error to a stern warning. Perhaps in the future the
compiler could resume emission of a hard error in the cases where the
EXTERNAL procedure is actually known to be called via its implicit
interface.
