[OPENMP]Fix PR49366: crash on VLAs in task untied regions.

We need to capture the local variables into a record in task untied
regions but clang does not support record with VLA data members.

Diffe

[OPENMP]Fix PR49366: crash on VLAs in task untied regions.

We need to capture the local variables into a record in task untied
regions but clang does not support record with VLA data members.

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

show more ...

Revert "Following up on PR48517, fix handling of template arguments that refer"

Combined with 'da98651 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d3) caused verifier
error

Revert "Following up on PR48517, fix handling of template arguments that refer"

Combined with 'da98651 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d3) caused verifier
errors when building Chromium. See https://crbug.com/1168494#c1 for a
reproducer.

Additionally it reverts changes that were dependent on this one, see
below.

> Following up on PR48517, fix handling of template arguments that refer
> to dependent declarations.
>
> Treat an id-expression that names a local variable in a templated
> function as being instantiation-dependent.
>
> This addresses a language defect whereby a reference to a dependent
> declaration can be formed without any construct being value-dependent.
> Fixing that through value-dependence turns out to be problematic, so
> instead this patch takes the approach (proposed on the core reflector)
> of allowing the use of pointers or references to (but not values of)
> dependent declarations inside value-dependent expressions, and instead
> treating template arguments as dependent if they evaluate to a constant
> involving such dependent declarations.
>
> This ends up affecting a bunch of OpenMP tests, due to OpenMP
> imprecisely handling instantiation-dependent constructs, bailing out
> early instead of processing dependent constructs to the extent possible
> when handling the template.
>
> Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and
> reverted because a dependency commit was reverted.

This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e.

It also restores clang/test/SemaCXX/coroutines.cpp to its state before
da986511fb9da1a46a0ca4dba2e49e2426036303.

Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."

> Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
> reverted because a dependency commit was reverted. This incorporates the
> following follow-on commits that were also reverted:
>
> 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim
> ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me
> 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall
> 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki

This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786.

Revert "[msabi] Mangle a template argument referring to array-to-pointer decay"

> [msabi] Mangle a template argument referring to array-to-pointer decay
> applied to an array the same as the array itself.
>
> This follows MS ABI, and corrects a regression from the implementation
> of generalized non-type template parameters, where we "forgot" how to
> mangle this case.

This reverts commit 18e093faf726d15f210ab4917142beec51848258.

show more ...

Following up on PR48517, fix handling of template arguments that refer
to dependent declarations.

Treat an id-expression that names a local variable in a templated
function as being instantiation-de

Following up on PR48517, fix handling of template arguments that refer
to dependent declarations.

Treat an id-expression that names a local variable in a templated
function as being instantiation-dependent.

This addresses a language defect whereby a reference to a dependent
declaration can be formed without any construct being value-dependent.
Fixing that through value-dependence turns out to be problematic, so
instead this patch takes the approach (proposed on the core reflector)
of allowing the use of pointers or references to (but not values of)
dependent declarations inside value-dependent expressions, and instead
treating template arguments as dependent if they evaluate to a constant
involving such dependent declarations.

This ends up affecting a bunch of OpenMP tests, due to OpenMP
imprecisely handling instantiation-dependent constructs, bailing out
early instead of processing dependent constructs to the extent possible
when handling the template.

Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and
reverted because a dependency commit was reverted.

show more ...

Revert "Following up on PR48517, fix handling of template arguments that refer"

This reverts commit 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e.

This is part of 5 commits being reverted due to https:/

Revert "Following up on PR48517, fix handling of template arguments that refer"

This reverts commit 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e.

This is part of 5 commits being reverted due to https://crbug.com/1161059. See bug for repro.

show more ...

Following up on PR48517, fix handling of template arguments that refer
to dependent declarations.

Treat an id-expression that names a local variable in a templated
function as being instantiation-de

Following up on PR48517, fix handling of template arguments that refer
to dependent declarations.

Treat an id-expression that names a local variable in a templated
function as being instantiation-dependent.

This addresses a language defect whereby a reference to a dependent
declaration can be formed without any construct being value-dependent.
Fixing that through value-dependence turns out to be problematic, so
instead this patch takes the approach (proposed on the core reflector)
of allowing the use of pointers or references to (but not values of)
dependent declarations inside value-dependent expressions, and instead
treating template arguments as dependent if they evaluate to a constant
involving such dependent declarations.

This ends up affecting a bunch of OpenMP tests, due to OpenMP
imprecisely handling instantiation-dependent constructs, bailing out
early instead of processing dependent constructs to the extent possible
when handling the template.

show more ...

[OpenMP] Add firstprivate as a default data-sharing attribute to clang

This implements the default(firstprivate) clause as defined in OpenMP
Technical Report 8 (2.22.4).

Reviewed By: jdoerfert, ABa

[OpenMP] Add firstprivate as a default data-sharing attribute to clang

This implements the default(firstprivate) clause as defined in OpenMP
Technical Report 8 (2.22.4).

Reviewed By: jdoerfert, ABataev

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

show more ...

[AST] dont invaliate VarDecl when the initializer contains errors.

Summary:
This patch contains 2 separate changes:
1) the initializer of a variable should play no part in decl "invalid" bit;
2) pre

[AST] dont invaliate VarDecl when the initializer contains errors.

Summary:
This patch contains 2 separate changes:
1) the initializer of a variable should play no part in decl "invalid" bit;
2) preserve the invalid initializer via recovery exprs;

With 1), we will regress the diagnostics (one big regression is that we loose
the "selected 'begin' function with iterator type" diagnostic in for-range stmt;
but with 2) together, we don't have regressions (the new diagnostics seems to be
improved).

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[OPENMP50]Mark expression in detach clause as firstprivate.

According to the standard, The event-handle will be considered as if it was specified on a firstprivate clause.

[OPENMP50]Initial support for detach clause in task directive.

Added parsing/sema/serialization support for detach clause.

[OPENMP]Initial fix PR42392: Improve -Wuninitialized warnings for OpenMP programs.

Summary:
Some OpenMP clauses rely on the values of the variables. If the variable
is not initialized and used in Op

[OPENMP]Initial fix PR42392: Improve -Wuninitialized warnings for OpenMP programs.

Summary:
Some OpenMP clauses rely on the values of the variables. If the variable
is not initialized and used in OpenMP clauses that depend on the
variables values, it should be reported that the uninitialized variable
is used in the OpenMP clause expression.
This patch adds initial processing for uninitialized variables in OpenMP
constructs. Currently, it checks for use of the uninitialized variables
in the structured blocks.

Reviewers: NoQ, Szelethus, dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet

Subscribers: rnkovacs, guansong, jfb, jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 365786

show more ...

[OPENMP]Add -Wunintialized to the erroneous tests for future fix PR42392,
NFC.

llvm-svn: 365334

[OPENMP]Fix PR41768: check DSA for globals with default(none) clauses.

If the default(none) was specified for the construct, we might miss
diagnostic for the globals without explicitly specified dat

[OPENMP]Fix PR41768: check DSA for globals with default(none) clauses.

If the default(none) was specified for the construct, we might miss
diagnostic for the globals without explicitly specified data-sharing
attributes. Patch fixes this problem.

llvm-svn: 360362

show more ...

Revert "[OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses."

This has introduced (exposed?) a crash in clang sema,
that does not happen without this patch.
I'll followup in the

Revert "[OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses."

This has introduced (exposed?) a crash in clang sema,
that does not happen without this patch.
I'll followup in the original bugreport and commit with reproducer.

This reverts commit r360061.

llvm-svn: 360327

show more ...

[OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses.

If the `default(none)` was specified for the construct, we might miss
diagnostic for the globals without explicitly specified

[OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses.

If the `default(none)` was specified for the construct, we might miss
diagnostic for the globals without explicitly specified data-sharing
attributes. Patch fixes this problem.

llvm-svn: 360061

show more ...

Incorrect implicit data-sharing for nested tasks

Summary:
There is a minor issue in how the implicit data-sharings for nested tasks are computed.

For the following example:
```
int x;
#pragma omp t

Incorrect implicit data-sharing for nested tasks

Summary:
There is a minor issue in how the implicit data-sharings for nested tasks are computed.

For the following example:
```
int x;
#pragma omp task shared(x)
#pragma omp task
x++;
```
We compute an implicit data-sharing of shared for `x` in the second task although I think that it should be firstprivate. Below you can find the part of the OpenMP spec that covers this example:
- // In a task generating construct, if no default clause is present, a variable for which the data-sharing attribute is not determined by the rules above and that in the enclosing context is determined to be shared by all implicit tasks bound to the current team is shared.//
- //In a task generating construct, if no default clause is present, a variable for which the data-sharing attribute is not determined by the rules above is firstprivate.//

Since each implicit-task has its own copy of `x`, we shouldn't apply the first rule.

Reviewers: ABataev

Reviewed By: ABataev

Subscribers: cfe-commits, rogfer01

Tags: #openmp

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

llvm-svn: 350734

show more ...

[OPENMP]Fix PR39372: Does not complain about loop bound variable not
being shared.

According to the standard, the variables with unspecified data-sharing
attributes in presence of `default(none)` cl

[OPENMP]Fix PR39372: Does not complain about loop bound variable not
being shared.

According to the standard, the variables with unspecified data-sharing
attributes in presence of `default(none)` clause must be reported to
users. Compiler did not generate error reports for the variables used in
other OpenMP regions. Patch fixes this.

llvm-svn: 345533

show more ...

[OPENMP] Support for -fopenmp-simd option with compilation of simd loops
only.

Added support for -fopenmp-simd option that allows compilation of
simd-based constructs without emission of OpenMP runt

[OPENMP] Support for -fopenmp-simd option with compilation of simd loops
only.

Added support for -fopenmp-simd option that allows compilation of
simd-based constructs without emission of OpenMP runtime calls.

llvm-svn: 321560

show more ...

[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses.

OpenMP 4.0 allows to define custom reduction operations using '#pragma
omp declare reduction' construct. Patch allows to use t

[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses.

OpenMP 4.0 allows to define custom reduction operations using '#pragma
omp declare reduction' construct. Patch allows to use this custom
defined reduction operations in 'reduction' clauses.

llvm-svn: 263701

show more ...

[OPENMP 4.1] Allow variables with reference types in private clauses.

OpenMP 4.1 allows to use variables with reference types in all private clauses (private, firstprivate, lastprivate, linear etc.)

[OPENMP 4.1] Allow variables with reference types in private clauses.

OpenMP 4.1 allows to use variables with reference types in all private clauses (private, firstprivate, lastprivate, linear etc.). Patch allows to use such variables and fixes codegen for linear variables with reference types.

llvm-svn: 245268

show more ...

[OPENMP] -fopenmp enables OpenMP support (fix for http://llvm.org/PR23492)

-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option tha

[OPENMP] -fopenmp enables OpenMP support (fix for http://llvm.org/PR23492)

-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736

llvm-svn: 237769

show more ...

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219306

show more ...

Revert commit r219297.
Still troubles with OpenMP/parallel_firstprivate_codegen.cpp (now in ARM buildbots).

llvm-svn: 219298

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219297

show more ...

Revert back r219295.
To fix issues with test OpenMP/parallel_firstprivate_codegen.cpp

llvm-svn: 219296

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These

[OPENMP] Codegen for 'firstprivate' clause.
This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy.
In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D5140

llvm-svn: 219295

show more ...