Reword OpenMP diagnostics for style; NFC

Three different OpenMP diagnostics were starting with a capital letter,
so this makes them all lowercase and updates the tests accordingly.

Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821)

… (#90885)"

This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.

Revert "Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91141)"

This reverts commit a99ce615f19fec6fbb835490b89f53cba3cf9eff.

Caused test failure on following buildbot:
htt

Revert "Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91141)"

This reverts commit a99ce615f19fec6fbb835490b89f53cba3cf9eff.

Caused test failure on following buildbot:
https://lab.llvm.org/buildbot/#/builders/139/builds/65066

show more ...

Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91141)

… (#90885)"

This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.

Also change isMapType as @vitalybuka s

Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91141)

… (#90885)"

This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.

Also change isMapType as @vitalybuka suggested. Hope this fix sanitizer
build problem.

show more ...

Revert "[OpenMP][TR12] change property of map-type modifier." (#90885)

Breaks
https://lab.llvm.org/buildbot/#/builders/5/builds/43086/steps/9/logs/stdio

Reverts llvm/llvm-project#90499

[OpenMP][TR12] change property of map-type modifier. (#90499)

map-type change to "default" instead "ultimate" from [OpenMP5.2]

The change is allowed map-type to be placed any locations within map

[OpenMP][TR12] change property of map-type modifier. (#90499)

map-type change to "default" instead "ultimate" from [OpenMP5.2]

The change is allowed map-type to be placed any locations within map
modifiers, besides the last location in the modifiers-list, also
map-type can be omitted afterward.

show more ...

[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534)

The syntax of modifiers without comma separators in the map clause was
deprecated in OpenMP 5.2.

Reference: OpenM

[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534)

The syntax of modifiers without comma separators in the map clause was
deprecated in OpenMP 5.2.

Reference: OpenMP 5.2 Spec, page 627, line 19

show more ...

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, t

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

# RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

# Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

# Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

# Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

# If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

# Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

# To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

Differential Revision: https://reviews.llvm.org/D129635

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)

show more ...

Add Parse/Sema for iterator for map clause.

[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2)

This patch implements Clang support for an original OpenMP extension
we have developed to support OpenACC: the `omp

[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2)

This patch implements Clang support for an original OpenMP extension
we have developed to support OpenACC: the `ompx_hold` map type
modifier. The next patch in this series, D106510, implements OpenMP
runtime support.

Consider the following example:

```
#pragma omp target data map(ompx_hold, tofrom: x) // holds onto mapping of x
{
foo(); // might have map(delete: x)
#pragma omp target map(present, alloc: x) // x is guaranteed to be present
printf("%d\n", x);
}
```

The `ompx_hold` map type modifier above specifies that the `target
data` directive holds onto the mapping for `x` throughout the
associated region regardless of any `target exit data` directives
executed during the call to `foo`. Thus, the presence assertion for
`x` at the enclosed `target` construct cannot fail. (As usual, the
standard OpenMP reference count for `x` must also reach zero before
the data is unmapped.)

Justification for inclusion in Clang and LLVM's OpenMP runtime:

* The `ompx_hold` modifier supports OpenACC functionality (structured
reference count) that cannot be achieved in standard OpenMP, as of
5.1.
* The runtime implementation for `ompx_hold` (next patch) will thus be
used by Flang's OpenACC support.
* The Clang implementation for `ompx_hold` (this patch) as well as the
runtime implementation are required for the Clang OpenACC support
being developed as part of the ECP Clacc project, which translates
OpenACC to OpenMP at the directive AST level. These patches are the
first step in upstreaming OpenACC functionality from Clacc.
* The Clang implementation for `ompx_hold` is also used by the tests
in the runtime implementation. That syntactic support makes the
tests more readable than low-level runtime calls can. Moreover,
upstream Flang and Clang do not yet support OpenACC syntax
sufficiently for writing the tests.
* More generally, the Clang implementation enables a clean separation
of concerns between OpenACC and OpenMP development in LLVM. That
is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's
extended OpenMP implementation and test suite without directly
considering OpenACC's language and execution model, which can be
handled by LLVM's OpenACC developers.
* OpenMP users might find the `ompx_hold` modifier useful, as in the
above example.

See new documentation introduced by this patch in `openmp/docs` for
more detail on the functionality of this extension and its
relationship with OpenACC. For example, it explains how the runtime
must support two reference counts, as specified by OpenACC.

Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new
command-line option introduced by this patch, is specified.

Reviewed By: ABataev, jdoerfert, protze.joachim, grokos

Differential Revision: https://reviews.llvm.org/D106509

show more ...

Stop emit incomplete type error for a variable in a map clause
where should not.

Currently we are using QTy->isIncompleteType(&ND) to check incomplete
type. But before doing that, need to instantia

Stop emit incomplete type error for a variable in a map clause
where should not.

Currently we are using QTy->isIncompleteType(&ND) to check incomplete
type. But before doing that, need to instantiate for a class template
specialization or a class member of a class template specialization,
or an array with known size of such..., so that we know it is really
incomplete type.

To fix this using RequireCompleteType instead.

The new test is added into "test/OpenMP/target_update_messages.cpp"

The different of using RequireCompleteType is when emit incomplete type,
an additional note is also emitted to point to where incomplete type
is declared. Because this change, many tests are needed to be fixed
by adding additional note.

This is to fix https://bugs.llvm.org/show_bug.cgi?id=50508

Differential Revision: https://reviews.llvm.org/D107200

show more ...

[OPENMP50]Allow overlapping mapping in target constructs.

OpenMP 5.0 removed a lot of restriction for overlapped mapped items
comparing to OpenMP 4.5. Patch restricts the checks for overlapped data

[OPENMP50]Allow overlapping mapping in target constructs.

OpenMP 5.0 removed a lot of restriction for overlapped mapped items
comparing to OpenMP 4.5. Patch restricts the checks for overlapped data
mappings only for OpenMP 4.5 and less and reorders mapping of the
arguments so, that present and alloc mappings are processed first and
then all others.

Differential Revision: https://reviews.llvm.org/D86119

show more ...

[OpenMP 5.0] Fix PR-45212: Shouldn't error out while using overloaded operator for map clause

LValue map checker should handle CXXOperatorCallExpr

Reviewed By: jdoerfert

Differential Revision: htt

[OpenMP 5.0] Fix PR-45212: Shouldn't error out while using overloaded operator for map clause

LValue map checker should handle CXXOperatorCallExpr

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D85563

show more ...

[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2)

This patch implements Clang front end support for the OpenMP TR8
`present` map type modifier. The next patch in this series impleme

[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2)

This patch implements Clang front end support for the OpenMP TR8
`present` map type modifier. The next patch in this series implements
OpenMP runtime support.

This patch does not attempt to implement TR8 sec. 2.22.7.1 "map
Clause", p. 319, L14-16:

> If a map clause with a present map-type-modifier is present in a map
> clause, then the effect of the clause is ordered before all other
> map clauses that do not have the present modifier.

Compare to L10-11, which Clang does not appear to implement yet:

> For a given construct, the effect of a map clause with the to, from,
> or tofrom map-type is ordered before the effect of a map clause with
> the alloc, release, or delete map-type.

This patch also does not implement the `present` implicit-behavior for
`defaultmap` or the `present` motion-modifier for `target update`.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D83061

show more ...

[OPENMP50]Perform data mapping analysis only for explicitly mapped data.

Summary:
According to OpenMP 5.0, the restrictions for mapping of overlapped data
apply only for explicitly mapped data, ther

[OPENMP50]Perform data mapping analysis only for explicitly mapped data.

Summary:
According to OpenMP 5.0, the restrictions for mapping of overlapped data
apply only for explicitly mapped data, there is no restriction for
implicitly mapped data just like in OpenMP 4.5.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin

Tags: #clang

Differential Revision: https://reviews.llvm.org/D83398

show more ...

[OPENMP50] extend array section for stride (Parsing/Sema/AST)

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: yaxunl, guansong, arphaman, sstefan1, cfe-commits, sandoval, dreachem

[OPENMP50] extend array section for stride (Parsing/Sema/AST)

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: yaxunl, guansong, arphaman, sstefan1, cfe-commits, sandoval, dreachem

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82800

show more ...

[OpenMP] Upgrade default version of OpenMP to 5.0

Summary:
When -fopenmp option is specified then version 5.0 will be set as
default.

Reviewers: gregrodgers, jdoerfert, ABataev

Reviewed By: ABatae

[OpenMP] Upgrade default version of OpenMP to 5.0

Summary:
When -fopenmp option is specified then version 5.0 will be set as
default.

Reviewers: gregrodgers, jdoerfert, ABataev

Reviewed By: ABataev

Subscribers: pdhaliwal, yaxunl, guansong, sstefan1, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D81098

show more ...

[OPENMP50]Initial support for use_device_addr clause.

Summary:
Added parsing/sema analysis/serialization support for use_device_addr
clauses.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, ar

[OPENMP50]Initial support for use_device_addr clause.

Summary:
Added parsing/sema analysis/serialization support for use_device_addr
clauses.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, arphaman, sstefan1, llvm-commits, cfe-commits, caomhin

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D80404

show more ...

Add map-type check for target and target data directive, by Chi Chun
Chen

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: cfe-commits, dreachem, sandoval

Tags: #clang

Differentia

Add map-type check for target and target data directive, by Chi Chun
Chen

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: cfe-commits, dreachem, sandoval

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77581

show more ...

[OPENMP50]Codegen for array shaping expression in map clauses.

Added codegen support for array shaping operations in map/to/from
clauses.

[OpenMP5.0] Allow pointer arithmetic in motion/map clause, by Chi Chun
Chen

Summary:
Base declaration in pointer arithmetic expression is determined by
binary search with type information. Take "int

[OpenMP5.0] Allow pointer arithmetic in motion/map clause, by Chi Chun
Chen

Summary:
Base declaration in pointer arithmetic expression is determined by
binary search with type information. Take "int *a, *b; *(a+*b)" as an
example, we determine the base by checking the type of LHS and RHS. In
this case the type of LHS is "int *", the type of RHS is "int",
therefore, we know that we need to visit LHS in order to find base
declaration.

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: guansong, cfe-commits, sandoval, dreachem

Tags: #clang

Differential Revision: https://reviews.llvm.org/D75077

show more ...

[OPENMP]Improve handling of possibly incorrectly mapped types.

Need to analayze the type of the expression for mapping, not the type of
the declaration.