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 ...

[test] %clang_cc1: remove redundant actions

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 ...

Fix accsessing "PresentModifierLocs" array beyond its end. (#73579)

Currently PresentModifierLocs defined with size DefaultmapKindNum; where
DefaultmapKindNum = OMPC_DEFAULTMAP_pointer + 1

Befor

Fix accsessing "PresentModifierLocs" array beyond its end. (#73579)

Currently PresentModifierLocs defined with size DefaultmapKindNum; where
DefaultmapKindNum = OMPC_DEFAULTMAP_pointer + 1

Before 5.0 variable-category can not be omitted. For the test like
\#pragma omp target map(tofrom: errors) defaultmap(present)

error would be mitted.

After 5.0 that is allowd.

When try to:
PresentModifierLocs[DMC->getDefaultmapKind()] =
DMC->getDefaultmapModifierLoc();
It is accessed beyond array end.

To fix this using OMPC_DEFAULTMAP_unknow instead OMPC_DEFAULTMAP_poiner.

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][5.1] Support `thread_limit` on `omp target`

It is unclear to me what happens if we have two thread_limit clauses to
choose from. I will recommend to the standards committee to disallow
that

[OpenMP][5.1] Support `thread_limit` on `omp target`

It is unclear to me what happens if we have two thread_limit clauses to
choose from. I will recommend to the standards committee to disallow
that. For now, we pick the teams one.

Fixes https://github.com/llvm/llvm-project/issues/59940

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

show more ...

[OpenMP][Clang] Move partial support of reverse offload to a future version

OpenMP Spec 5.2 requires unimplemented requires clauses to produce
compile time error termination. Moving current partial

[OpenMP][Clang] Move partial support of reverse offload to a future version

OpenMP Spec 5.2 requires unimplemented requires clauses to produce
compile time error termination. Moving current partial support of
reverse_offload to a distant future version 9.9 so that existing
code can be tested and maintained until a complete implementation
is available.

Reviewed By: ABataev

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

show more ...

[OpenMP][Clang] Allow ancestor device modifier only with reverse offloading

OpenMP Spec 5.0 [2.12.5, Restrictions]: If a device clause in which the
ancestor device-modifier appears is present on the

[OpenMP][Clang] Allow ancestor device modifier only with reverse offloading

OpenMP Spec 5.0 [2.12.5, Restrictions]: If a device clause in which the
ancestor device-modifier appears is present on the target construct,
then a requires directive with the reverse_offload clause must be
specified.

Reviewed By: ABataev

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

show more ...

[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 ...

[OPENMP51] Add present modifier in defaultmap clause

Support present modifier in defaultmap by adding an extra dimension
for `ImplicitMap`. Therefore, we now create OMPMapClause in `ActOnOpenMPExecu

[OPENMP51] Add present modifier in defaultmap clause

Support present modifier in defaultmap by adding an extra dimension
for `ImplicitMap`. Therefore, we now create OMPMapClause in `ActOnOpenMPExecutableDirective`
based on both `maptype` and `maptype-modifier`.

Reviewed By: ABataev

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

show more ...

[OpenMP] Ensure testing for versions 4.5 and default - Part 1

Many OpenMP Clang tests do not RUN for version 4.5 and the default
version. This first patch in the series only handles test cases
which

[OpenMP] Ensure testing for versions 4.5 and default - Part 1

Many OpenMP Clang tests do not RUN for version 4.5 and the default
version. This first patch in the series only handles test cases
which do not require any modifications in the CHECK lines after
adding RUN lines for default version.

Reviewed By: ABataev

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

show more ...

[OPENMP]Consider 'omp_null_allocator' as a predefined allocator.

Summary:
omp.h header file defines omp_null_allocator as a predefined allocator,
need to consider it also as a predefined allocator.

[OPENMP]Consider 'omp_null_allocator' as a predefined allocator.

Summary:
omp.h header file defines omp_null_allocator as a predefined allocator,
need to consider it also as a predefined allocator.

Reviewers: jdoerfert

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

Tags: #clang

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

show more ...

[OPENMP50]Basic support for uses_allocators clause.

Summary: Added parsing/sema/serialization supoprt for uses_allocators clause.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, arphaman, cfe-

[OPENMP50]Basic support for uses_allocators clause.

Summary: Added parsing/sema/serialization supoprt for uses_allocators clause.

Reviewers: jdoerfert

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

Tags: #clang

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

show more ...

[OPENMP50] Fix PR45469: Consider variable-category of defaultmap clause as optional.

Summary:
According to the standard, variable-category is the optional part of the
defaultmap clause while the com

[OPENMP50] Fix PR45469: Consider variable-category of defaultmap clause as optional.

Summary:
According to the standard, variable-category is the optional part of the
defaultmap clause while the compiler always requires it. Turned it into
optional part.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, cfe-commits, caomhin

Tags: #clang

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

show more ...

[OPENMP50]Add support for extended device clause in target directives.

Added parsing/sema/serialization support for extended device clause in
executable target directives.

[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen.

Summary:
For the extended defaultmap, most of the work is inside sema.
The only difference for codegen is to set different initial
maptype for dif

[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen.

Summary:
For the extended defaultmap, most of the work is inside sema.
The only difference for codegen is to set different initial
maptype for different implicit-behavior.

Reviewers: jdoerfert, ABataev

Reviewed By: ABataev

Subscribers: dreachem, sandoval, cfe-commits

Tags: #clang, #openmp

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

show more ...

[OpenMP] Added support for explicit mapping of classes using 'this' pointer. Differential revision: https://reviews.llvm.org/D55982

llvm-svn: 350252