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>
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.
I just introduced a dependency from the Evaluate library to the
Semantics library, which is circular in a shared library build.
Rearrange the code a little to ensure that the dependence is only on a
header.
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.
For test program like this variable array is mentioned in both shared
clause and map clause. For OMP TARGET compound directives like this
where we have OMP TARGET TEAMS, map clause applies to TARGET directive
and SHARED clause applies to TEAMS directive. So both SHARED and MAP
clauses can co-exist.
> program test
> implicit none
> integer :: array(10,10),i,j
> !$omp target teams shared(array) map(tofrom:array)
> do i=1,10
> !$omp parallel do
> do j=1,10
> array(j,i)=i+j
> end do
> end do
> !$omp end target teams
> print *, array
> end program test
>
>
Before this PR we were checking for exclusivity for all target
directives set which is now relaxed to exclusivity check not being
applied to compound directives which can accept SHARED clause.
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 semantics utility GetAllNames has declarations in two header files
and a definition that really should be in the common utilities source
file. Remove the redudant declaration from resolve-names-utils.h and
move code from resolve-names-utils.cpp into Semantics/tools.cpp.
ProgramTree instances are created as the value of a local variable in
the Pre(const parser::ProgramUnit &) member function in name resolution.
But references to these ProgramTree instances can persist in
SubprogramNameDetails symbol table entries that might survive that
function call's lifetime, and lead to trouble later when (e.g.)
expression semantics needs to deal with a possible forward reference in
a function reference in an expression being processed later in
expression checking.
So put those ProgramTree instances into a longer-lived linked list
within the SemanticsContext.
Might fix some weird crashes reported on big-endian targets (AIX &
Solaris).
Add the permutation clause for the interchange directive which will be
introduced in the upcoming OpenMP 6.0 specification. A preview has been
published in
[Technical Report12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
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>
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
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.
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.
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
As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly
( 65b13610a5 for further reference )
Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
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
When a function result type appears on a FUNCTION statement after some
CUDA attributes, there wasn't always valid program source location
information attached to the function result variable information stack.
Ensure that some relevant source information is always available.
