flang incorrectly issues a semantic erorr when a `cycle` statement is
used inside a `target teams distribute [simd]` associated loop. This is
not prevented by the spec, therefore this PR allows such construct.
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.
(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().
shortloop is a non standard OpenACC extension
(https://docs.nvidia.com/hpc-sdk/pgi-compilers/2015/pgirn157.pdf) that
can be found on loop directives.
f18 parser was choking when seeing it. Since it can be found in existing
apps and is mainly an optimization hint, parse it on loop directives and
ignore it with a warning.
For the records, here is shortloop meaning according to the manual linked above:
"If the shortloop clause appears on a loop directive with the vector clause, it tells the compiler that the
loop trip count is less than or equal to the number of vector lanes created for that loop. This means the
value of the vector() clause on the loop directive in a kernels region, or the value of the
vector_length() clause on the parallel directive in a parallel region will be greater than or
equal to the loop trip count. This allows the compiler to generate more efficient code for the loop"
Four "issues" on GitHub report possible performance problems, likely
detected by static analysis. None of them would ever make a measureable
difference in compilation time, but I'm resolving them to clean up the
open issues list.
Fixes https://github.com/llvm/llvm-project/issues/79703, .../79705,
.../79706, & .../79707.
this patch enforce or fix the enforcement of two restrictions from
section 2.15.1:
> Only the gang, worker, vector, seq and bind clauses may follow a
device_type clause.
`seq` was not allowed after `device_type` with the current
implementation.
> Exactly one of the gang, worker, vector, or seq clauses must appear.
This was not properly checked. This patch check correctly for mutually
exclusion as described in section 2.4. Mutually exclusive clauses may
appear on the same directive if they apply for different device_type.
Some clauses can be repeated on the compute construct when they are
placed after `device_type`. The semantic check was reporting an error
for these cases. This patch fixes this.
Unlike mentioned in #73839, some OpenACC construct still need the cycle
branching check to be performed. This patch adds a list of construct
where the check is not needed (loop and combined construct) and add
tests to check where it is still needed.
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.
For portability with other compilers, just issue a portability warning
instead of a hard error when `num_gangs`, `num_workers` or
`vector_length` are present on an `!$acc serial` directive
Some compilers accept `!$acc data` without any clauses. For portability
reason, this patch relaxes the strict error to a simple portability warning.
Reviewed By: razvanlupusoru, vzakhari
Differential Revision: https://reviews.llvm.org/D159019
This reverts commit 02fa9fc018db5b757a4ce129d85d64efefc8645c.
Commit message and content does not match. Revert to commit with
a proper commit message.
This patch supports the following checks for ORDERED construct:
```
[5.1] 2.19.9 ORDERED Construct
The worksharing-loop or worksharing-loop SIMD region to which an ordered
region corresponding to an ordered construct without a depend clause
binds must have an ordered clause without the parameter specified on the
corresponding worksharing-loop or worksharing-loop SIMD directive.
The worksharing-loop region to which an ordered region that corresponds
to an ordered construct with any depend clauses binds must have an
ordered clause with the parameter specified on the corresponding
worksharing-loop directive.
An ordered construct with the depend clause specified must be closely
nested inside a worksharing-loop (or parallel worksharing-loop)
construct.
An ordered region that corresponds to an ordered construct with the simd
clause specified must be closely nested inside a simd or
worksharing-loop SIMD region.
```
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D113399
Device clause when it occurs with **target enter data** and **target exit data** must be declared with some non negative value. So some changes were made to evaluate the device clause argument to non negative value and throw the expected error when it takes negative value as argument.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119141
According to OpenMP 5.0 spec document, the following semantic restrictions have been dealt with in this patch.
1. [sections construct] Orphaned section directives are prohibited. That is, the section directives must appear within the sections construct and must not be encountered elsewhere in the sections region.
Semantic checks for the following are not necessary, since use of orphaned section construct (i.e. without an enclosing sections directive) throws parser errors and control flow never reaches the semantic checking phase. Added a test case for the same.
2. [sections construct] Must be a structured block
Added test case and made changes to branching logic
3. [simd construct] Must be a structured block / A program that branches in or out of a function with declare simd is non conforming
4. Fixed !$omp do's handling of unlabeled CYCLEs
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D108904
This patch implements the following check for TEAMS construct:
```
OpenMP Version 5.0 Teams construct restriction: A teams region can
only be strictly nested within the implicit parallel region or a target
region. If a teams construct is nested within a target construct, that
target construct must contain no statements, declarations or directives
outside of the teams construct.
```
Also add one test case for the check.
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D106335
Semantic checks for the following OpenMP 4.5 clauses.
1. 2.15.4.2 - Copyprivate clause
2. 2.15.3.4 - Firstprivate clause
3. 2.15.3.5 - Lastprivate clause
Add related test cases and resolve test cases marked as XFAIL.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91920
Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the 'do' iteration variable is a variable in 'Firstprivate' clause.
Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp
Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D93205
`DirectiveStructureChecker` was passing in a pointer to a temporary
string for the `construct` argument to the constructor for `LabelEnforce`.
The `LabelEnforce` object had a lifetime longer than the temporary,
resulting in accessing a dangling pointer when emitting an error message
for `omp-parallell01.f90`.
The fix is to make the lifetime of the temporary as long as the lifetime
of the `LabelEnforce` object.
Differential Revision: https://reviews.llvm.org/D94618
`CheckNoBranching` is currently handling only illegal branching out for constructs
with `Parser::Name` in them.
Extend the same for handling illegal branching out caused by `Parser::Label` based statements.
This patch could possibly solve one of the issues(typically branching out) mentioned in D92735.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93447
Remove duplicated function to check for required clauses on a directive. This was
still there from the merging of OpenACC and OpenMP common semantic checks and it can now be
removed so we use only one function.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93575
Some changes introduced in https://reviews.llvm.org/D88655 cause compiler
warnings. Since in Flang warnings are treated as errors (`-Werror` is on by
default), these are in practice compiler errors (verified with clang-10 and
clang-11, gcc-10). This patches fixes these warning/failures.
Warning/error 1:
```
llvm-project/flang/lib/Semantics/check-omp-structure.cpp:107:3: error:
unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
```
Warning/error 2:
```
llvm-project/flang/lib/Semantics/check-directive-structure.h:39:9: error: field
'currentDirective_' will be initialized after field 'upperCaseDirName_'
[-Werror,-Wreorder-ctor]
```
Failing buildbot:
* http://lab.llvm.org:8011/#/builders/33/builds/386
From below mentioned standard references
OpenACC 3.0 Standards document
840 • A program may not branch into or out of an OpenACC parallel construct
OpenMP 5.0 Standards document
A program that branches into or out of a parallel region is non-conforming.
This patch
Resolves the issue of exit out of a parallel region, other branching out issues like goto statements are not handled with this patch.
Moves code from D87906 to be reused by other OpenMP/OpenACC to check-directive-structure.h.
Adds support in OpenMP parallel construct and a test case to verify.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D88655
Clang 9 gets the following warning after revision `D85104`.
```
../../flang/lib/Semantics/check-directive-structure.h:36:7: error: 'Fortran::semantics::DirectiveStructureChecker<llvm::omp::Directive, llvm::omp::Clause, Fortran::parser::OmpClause, 77>' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
```
The fix is the make the destructor virtual. Neither it nor the
constructor need to be public, so make them protected.
Differential Revision: https://reviews.llvm.org/D85383
This patch remove duplicated code between the check-omp-structure and the check-acc-structure
and unify it into a check-directive-structure templated class.
Reviewed By: kiranchandramohan, sscalpone, ichoyjx
Differential Revision: https://reviews.llvm.org/D85104
