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)

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

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

According to OpenMP 5.0, range-based for is also considered as a
canonical form of loops.

llvm-svn: 373939

Chun Chen.

The previous patch (https://reviews.llvm.org/D54441) support the
relational-op != very well for openmp canonical loop form, however,
it didn't update the diagnosis message. So this patch is simply
update the diagnosis message by adding !=, update the test
related to it, and update the section number for canonical loop
form for OpenMP 5.0 in comment.

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

llvm-svn: 371631

NFC.

llvm-svn: 365334

forms of random access iterator
    
In OpenMP 4.5, only 4 relational operators are supported: <, <=, >, 
and >=.  This work is to enable support for relational operator 
!= (not-equal) as one of the canonical forms.

Patch by Anh Tuyen Tran
    
Differential Revision: https://reviews.llvm.org/D54441

llvm-svn: 347405

Summary:
First, this patch fixes an assert failure when, for example, "omp for"
has num_teams.

Second, this patch prevents duplicate diagnostics when, for example,
"omp for" has uniform.

This patch makes the general assumption (even where it doesn't
necessarily fix an existing bug) that it is worthless to perform sema
for a clause that appears on a directive on which OpenMP does not
permit that clause.  However, due to this assumption, this patch
suppresses some diagnostics that were expected in the test suite.  I
assert that those diagnostics were likely just distracting to the
user.

Reviewers: ABataev

Reviewed By: ABataev

Subscribers: cfe-commits

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

llvm-svn: 322107

only.

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

llvm-svn: 321560

step>1.

If the loop is a loot with random access iterators and the iteration
construct is represented it += n, then the compiler crashed because of
reusing of the same MaterializedTemporaryExpr around N. Patch fixes it
by using the expression as written, without any special kind of
wrappings.

llvm-svn: 312292