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.
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.
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.
(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().
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>
While experimenting with some more recent C++ features, I ran into
trouble with warnings from GCC 12.3.0 and 14.2.0. These warnings looked
legitimate, so I've tweaked the code to avoid them.
This patch restores the flang build, which was inadvertently broken by
the patch to implement 'omp assume' support
(a42e515e3a).
Thanks to Maxim Kuvyrkov and the Linaro auto-tester for the heads-up.
Extends the OmpCycleAndExitChecker to check that associated loops of a
loop construct are not DO WHILE or DO without control.
OpenMP 5.0 standard clearly mentions this restriction. Later standards
enforce this through the definition of associated loops and canonical
loop forms.
https://www.openmp.org/spec-html/5.0/openmpsu41.htmlFixes#81949
f18 current emits an error when an assignment is made to an array
section with a vector subscript, and the array is finalized with a
non-elemental final subroutine. Some other compilers emit this error
because (I think) they want variables to only be finalized in place, not
by a subroutine call involving copy-in & copy-out of the finalized
elements.
Since many other Fortran compilers can handle this case, and there's
nothing in the standards to preclude it, let's downgrade this error
message to a portability warning.
This patch got complicated because the API for the WhyNotDefinable()
utility routine was such that it would return a message only in error
cases, and there was no provision for returning non-fatal messages. It
now returns either nothing, a fatal message, or a non-fatal warning
message, and all of its call sites have been modified to cope.
In this case the union inside of the `parser::DefinedOperator` contains
a string name instead of the expected
`parser::DefinedOperator::IntrinsicOperator`. This led to a
`std::abort`.
This patch adapts the code so that if it contains a string name we emit
a semantic error.
Composite OpenMP constructs where DISTRIBUTE is the first leaf
construct, as well as standalone DISTRIBUTE constructs, are allowed
inside of TEAMS regions.
Before this patch, nesting a DISTRIBUTE construct inside of a combined
TARGET TEAMS construct was disallowed, which it shouldn't be. Now both
TEAMS and TARGET TEAMS constructs can be immediate parents of DISTRIBUTE
constructs.
Extend the checker that deals with CYCLE to handle EXIT also. The
difference for EXIT is that it is not allowed to EXIT from the innermost
associated loops while it is OK to CYCLE in the innermost associated
loop. Also add an incrementer on leaving the DO loop for EXIT checks.
Cycle is associated with construct-names and not labels. Change name of
a few variables to reflect this. Also add appropriate comment to
describe the else case of error checking.
…Warn()
Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.
…lastprivate
OpenMP 5.2 standard (Section 5.3) defines privatization for list items.
Section 3.2.1 in the standard defines list items to exclude variables
that are part of other variables.
This patch adds the restriction to firstprivate and lastprivates, it was
previously added for privates.
Fixes https://github.com/llvm/llvm-project/issues/67227
Note: The specific checks that are added here are explicitly called out
in OpenMP 4.0
(https://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf) Sections
2.14.3.4 and 2.14.3.5 but in later standards have become implicit
through other definitions.
When a local variable inside a BLOCK construct is used as threadprivate
variable, llvm-flang throws below error:
> error: The THREADPRIVATE directive and the common block or variable in
it must appear in the same declaration section of a scoping unit
Accept the reduction modifier in the Flang parser. Issue a TODO message
during lowering.
OpenMP 5.0 introduced the reduction modifier. Details can be seen in
2.19.5.4 reductionClause.
OpenMP 5.2 relevant section is 5.5.8reductionClause.
This will help remove some of the parser errors highlighted in the
following post and also bring it to a well defined behaviour (produce
TODO errors for unsupported features, do not crash).
https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/60
This effectively implements some now deprecated OpenMP functionality
that some applications (most notably at the moment GenASiS)
unfortunately depend on (deprecated in specification version 5.2):
"If a list item in a use_device_ptr clause is not of type C_PTR, the
behavior is as if the list item appeared in a use_device_addr clause.
Support for such list items in a use_device_ptr clause is deprecated."
This PR downgrades the hard-error to a deprecated warning and "promotes"
the above cases by simply moving the offending operands from the
use_device_ptr value list to the back of the use_device_addr list (and
moves the related symbols, locs and types that form the BlockArgs
correspondingly) and then the generation of the target data construct
proceeds as normal.
This patch adds support in flang for the depend clause in target and
target enter/update/exit constructs. Previously, the following line in a
fortran program would have resulted in the error shown below it.
!$omp target map(to:a) depend(in:a)
"not yet implemented: Unhandled clause DEPEND in TARGET construct"
This is a support for " #pragma omp atomic compare weak". It has Parser
& AST support for now.
---------
Authored-by: Sunil Kuravinakop <kuravina@pe28vega.us.cray.com>
Changed semantic check from giving error to giving a warning about
deprecation from OpenMP 5.2 and later about checks for dummy argument
list-items present on IS_DEVICE_PTR clause.
This P is blocker for
https://github.com/llvm/llvm-project/pull/71255
1. COPYPRIVATE clause should be specified on END SINGLE construct.
2. NOWAIT clause should be specified on END DO/DO SIMD/SINGLE/SECTIONS
construct.
Special handling for semantic checks for nowait/copyprivate clause is
needed in Fortran due to the fact that Openmp pragmas for C/C++ doesn't
have end directive (clause). nowait/copyprivate clauses are allowed in
begin directive clause lists for C/C++ and it is not allowed for
Fortran.
This patch adds the following semantic check:
```
The ancestor device-modifier must not appear on the device clause on any
directive other than the target construct.
```
This reverts commit edd675ac28.
This breaks clang build where every component is a shared library.
The file clang/lib/Basic/OpenMPKinds.cpp, which is a part of
libclangBasic.so, uses `getOpenMPClauseName` which isn't:
/usr/bin/ld: CMakeFiles/obj.clangBasic.dir/OpenMPKinds.cpp.o: in functio
n `clang ::getOpenMPSimpleClauseTypeName(llvm::omp::Clause, unsigned int
)':
OpenMPKinds.cpp:(.text._ZN5clang29getOpenMPSimpleClauseTypeNameEN4llvm3o
mp6ClauseEj+0x9b): undefined reference to `llvm::omp::getOpenMPClauseNam
e(llvm::omp::Clause)'
This patch adds the following check from OpenMP 5.2.
```
If the directive has a clause, it must contain at least one enter clause
or at least one link clause.
```
Also added a warning for the deprication of `TO` clause on `DECLARE
TARGET` construct.
```
The clause-name to may be used as a synonym for the clause-name enter.
This use has been deprecated.
```
Based on the tests for to clause, the tests for enter clause are added.
This patch does not add tests where both to and enter clause are used together.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.