[PATCH] D155852: [flang] Add -fppc-native-vector-element-order option to control the element order in PowerPC vector types

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG00769d69fbaa: [flang] Add -fppc-native-vector-element-order 
option to control the element… (authored by kkwli0).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155852/new/

https://reviews.llvm.org/D155852

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Lower/CustomIntrinsicCall.h
  flang/include/flang/Lower/LoweringOptions.def
  flang/include/flang/Optimizer/Builder/IntrinsicCall.h
  flang/include/flang/Optimizer/Builder/PPCIntrinsicCall.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Lower/ConvertExpr.cpp
  flang/lib/Lower/CustomIntrinsicCall.cpp
  flang/lib/Optimizer/Builder/IntrinsicCall.cpp
  flang/lib/Optimizer/Builder/PPCIntrinsicCall.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/frontend-forwarding.f90
  flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
  flang/tools/bbc/bbc.cpp

Index: flang/tools/bbc/bbc.cpp
===
--- flang/tools/bbc/bbc.cpp
+++ flang/tools/bbc/bbc.cpp
@@ -186,6 +186,11 @@
 llvm::cl::desc("enable polymorphic type lowering (experimental)"),
 llvm::cl::init(false));
 
+static llvm::cl::opt enableNoPPCNativeVecElemOrder(
+"fno-ppc-native-vector-element-order",
+llvm::cl::desc("no PowerPC native vector element order."),
+llvm::cl::init(false));
+
 static llvm::cl::opt useHLFIR("hlfir",
 llvm::cl::desc("Lower to high level FIR"),
 llvm::cl::init(false));
@@ -289,6 +294,7 @@
   // Use default lowering options for bbc.
   Fortran::lower::LoweringOptions loweringOptions{};
   loweringOptions.setPolymorphicTypeImpl(enablePolymorphic);
+  loweringOptions.setNoPPCNativeVecElemOrder(enableNoPPCNativeVecElemOrder);
   loweringOptions.setLowerToHighLevelFIR(useHLFIR || emitHLFIR);
   auto burnside = Fortran::lower::LoweringBridge::create(
   ctx, semanticsContext, defKinds, semanticsContext.intrinsics(),
Index: flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
===
--- /dev/null
+++ flang/test/Lower/PowerPC/ppc-vec_cvf-elem-order.f90
@@ -0,0 +1,37 @@
+! RUN: bbc -emit-fir %s -fno-ppc-native-vector-element-order=true -o - | FileCheck --check-prefixes="FIR" %s
+! RUN: %flang_fc1 -emit-llvm %s -fno-ppc-native-vector-element-order -o - | FileCheck --check-prefixes="LLVMIR" %s
+! REQUIRES: target=powerpc{{.*}}
+
+! CHECK-LABEL: vec_cvf_test_r4r8
+subroutine vec_cvf_test_r4r8(arg1)
+  vector(real(8)), intent(in) :: arg1
+  vector(real(4)) :: r
+  r = vec_cvf(arg1)
+
+! FIR: %[[arg:.*]] = fir.load %{{.*}} : !fir.ref>
+! FIR: %[[carg:.*]] = fir.convert %[[arg]] : (!fir.vector<2:f64>) -> vector<2xf64>
+! FIR: %[[call:.*]] = fir.call @llvm.ppc.vsx.xvcvdpsp(%[[carg]]) fastmath : (vector<2xf64>) -> !fir.vector<4:f32>
+! FIR: %[[ccall:.*]] = fir.convert %[[call]] : (!fir.vector<4:f32>) -> vector<4xf32>
+! FIR: %[[r:.*]] = fir.convert %[[ccall]] : (vector<4xf32>) -> !fir.vector<4:f32>
+! FIR: fir.store %[[r]] to %{{.*}} : !fir.ref>
+
+! LLVMIR: %[[arg:.*]] = load <2 x double>, ptr %{{.*}}, align 16
+! LLVMIR: %[[call:.*]] = call contract <4 x float> @llvm.ppc.vsx.xvcvdpsp(<2 x double> %[[arg]])
+! LLVMIR: store <4 x float> %[[call]], ptr %{{.*}}, align 16
+end subroutine vec_cvf_test_r4r8
+
+! CHECK-LABEL: vec_cvf_test_r8r4
+subroutine vec_cvf_test_r8r4(arg1)
+  vector(real(4)), intent(in) :: arg1
+  vector(real(8)) :: r
+  r = vec_cvf(arg1)
+
+! FIR: %[[arg:.*]] = fir.load %{{.*}} : !fir.ref>
+! FIR: %[[carg:.*]] = fir.convert %[[arg]] : (!fir.vector<4:f32>) -> vector<4xf32>
+! FIR: %[[call:.*]] = fir.call @llvm.ppc.vsx.xvcvspdp(%[[carg]]) fastmath : (vector<4xf32>) -> !fir.vector<2:f64>
+! FIR: fir.store %[[call]] to %{{.*}} : !fir.ref>
+
+! LLVMIR: %[[arg:.*]] = load <4 x float>, ptr %{{.*}}, align 16
+! LLVMIR: %[[r:.*]] = call contract <2 x double> @llvm.ppc.vsx.xvcvspdp(<4 x float> %[[arg]])
+! LLVMIR: store <2 x double> %[[r]], ptr %{{.*}}, align 16
+end subroutine vec_cvf_test_r8r4
Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -18,6 +18,8 @@
 ! RUN: -fversion-loops-for-stride \
 ! RUN: -flang-experimental-polymorphism \
 ! RUN: -flang-experimental-hlfir \
+! RUN: -fno-ppc-native-vector-element-order \
+! RUN: -fppc-native-vector-element-order \
 ! RUN: -mllvm -print-before-all \
 ! RUN: -save-temps=obj \
 ! RUN: -P \
@@ -40,5 +42,7 @@
 ! CHECK: "-fversion-loops-for-stride"
 ! CHECK: "-flang-experimental-polymorphism"
 ! CHECK: "-flang-experimental-hl

[PATCH] D140795: [Flang] Add user option -funderscoring/-fnounderscoring to enable/disable ExternalNameConversionPass

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D140795#4033559 , @awarzynski 
wrote:

>> However, I don't think the patch does what we want. Given a procedure name 
>> `foo`, the `-fno-underscoring` option will give `_QPfoo` instead of `foo`. 
>> We will look into it.
>
> Names in Flang are mangled at the FIR level. I couldn't find any 
> documentation for this, but the ExternalNameConversion 
> 
>  pass could be helpful.

@awarzynski Thanks for the info. We intend to make use of 
`ExternalNameConversion` for this purpose. However, we are not sure how a 
compiler option can control the behavior in `ExternalNameConversion`. Any 
pointer to how other passes do it is appreciated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140795/new/

https://reviews.llvm.org/D140795

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D140795: [Flang] Add user option -funderscoring/-fnounderscoring to enable/disable ExternalNameConversionPass

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D140795#4022493 , @awarzynski 
wrote:

> Hi @madanial , thanks for posting this!
>
>> This patch adds user option -funderscoring/-fnounderscoring which behaves 
>> similar to the gfortran option be enabling/disabling the 
>> ExternalNameConversionPass
>
> I don't quite understand what this option is for and it's hard to deduce from 
> the patch. Please, could you add a link to some documentation? And tests.
>
> -Andrzej

@awarzynski  Thanks for the review. @madanial will not be available for the 
next few weeks. I will try to address some review comments while he is away.

The purpose of this option is to control the trailing underscore being appended 
to external names (e.g. procedure names, common block names). The option in 
gfortran is documented in 
https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html.

However, I don't think the patch does what we want. Given a procedure name 
`foo`, the `-fno-underscoring` option will give `_QPfoo` instead of `foo`. We 
will look into it.

However, I don't think the patch does what we want. Given a procedure name 
`foo`, the `-fno-underscoring` option will give `_QPfoo` instead of `foo`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140795/new/

https://reviews.llvm.org/D140795

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118965: [OpenMP] Add search path for llvm-strip

[Kelvin Li via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ea4aed50a9f: [OpenMP] Add search path for llvm-strip 
(authored by kkwli0).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118965/new/

https://reviews.llvm.org/D118965

Files:
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -310,7 +310,13 @@
 
   // We will use llvm-strip to remove the now unneeded section containing the
   // offloading code.
-  ErrorOr StripPath = sys::findProgramByName("llvm-strip");
+  void *P = (void *)(intptr_t)&Help;
+  StringRef COWDir = "";
+  auto COWPath = sys::fs::getMainExecutable("llvm-strip", P);
+  if (!COWPath.empty())
+COWDir = sys::path::parent_path(COWPath);
+  ErrorOr StripPath =
+  sys::findProgramByName("llvm-strip", {COWDir});
   if (!StripPath)
 return createStringError(StripPath.getError(),
  "Unable to find 'llvm-strip' in path");


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -310,7 +310,13 @@
 
   // We will use llvm-strip to remove the now unneeded section containing the
   // offloading code.
-  ErrorOr StripPath = sys::findProgramByName("llvm-strip");
+  void *P = (void *)(intptr_t)&Help;
+  StringRef COWDir = "";
+  auto COWPath = sys::fs::getMainExecutable("llvm-strip", P);
+  if (!COWPath.empty())
+COWDir = sys::path::parent_path(COWPath);
+  ErrorOr StripPath =
+  sys::findProgramByName("llvm-strip", {COWDir});
   if (!StripPath)
 return createStringError(StripPath.getError(),
  "Unable to find 'llvm-strip' in path");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118965: [OpenMP] Add search path for llvm-strip

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: jhuber6, jdoerfert.
Herald added subscribers: guansong, yaxunl.
kkwli0 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Add the search path for llvm-strip instead of solely relying on the PATH 
environment variable setting.

Currently, `make check-openmp` has a few failures with the error:

  /build-llvm/./bin/clang-linker-wrapper: error: Unable to find 'llvm-strip' in 
path


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118965

Files:
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -303,7 +303,13 @@
 
   // We will use llvm-strip to remove the now unneeded section containing the
   // offloading code.
-  ErrorOr StripPath = sys::findProgramByName("llvm-strip");
+  void *P = (void *)(intptr_t)&Help;
+  StringRef COWDir = "";
+  auto COWPath = sys::fs::getMainExecutable("llvm-strip", P);
+  if (!COWPath.empty())
+COWDir = sys::path::parent_path(COWPath);
+  ErrorOr StripPath =
+  sys::findProgramByName("llvm-strip", {COWDir});
   if (!StripPath)
 return createStringError(StripPath.getError(),
  "Unable to find 'llvm-strip' in path");


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -303,7 +303,13 @@
 
   // We will use llvm-strip to remove the now unneeded section containing the
   // offloading code.
-  ErrorOr StripPath = sys::findProgramByName("llvm-strip");
+  void *P = (void *)(intptr_t)&Help;
+  StringRef COWDir = "";
+  auto COWPath = sys::fs::getMainExecutable("llvm-strip", P);
+  if (!COWPath.empty())
+COWDir = sys::path::parent_path(COWPath);
+  ErrorOr StripPath =
+  sys::findProgramByName("llvm-strip", {COWDir});
   if (!StripPath)
 return createStringError(StripPath.getError(),
  "Unable to find 'llvm-strip' in path");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Is the diff from HEAD?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98798/new/

https://reviews.llvm.org/D98798

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 accepted this revision.
kkwli0 added a comment.
This revision is now accepted and ready to land.

No more comments from the community.  I think it is okay to accept this 
revision.  Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

I tried the patch in our environment and it works.  LG.  Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98902/new/

https://reviews.llvm.org/D98902

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86562: [OPENMP][NFC]Release notes for OpenMP in clang (11.x).

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

`default(firstprivate)` was added in 
https://reviews.llvm.org/rG78443666bc18a6957d279a0f58319c8a3e57771a


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86562/new/

https://reviews.llvm.org/D86562

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86562: [OPENMP][NFC]Release notes for OpenMP in clang (11.x).

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

`present` map type and motion modifier
`default(firstprivate)`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86562/new/

https://reviews.llvm.org/D86562

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:7046-7049
+/// Signal that the runtime library should use args as an array of
+/// descriptor_dim pointers and use args_size as dims. Used when we have
+/// non-contiguous list items in target update directive
+OMP_MAP_DESCRIPTOR = 0x800,

ABataev wrote:
> cchen wrote:
> > ABataev wrote:
> > > I'm not sure about the value of this flag. If I do recall it correctly, 
> > > this value might be used for something different by XL compiler, for 
> > > example. Maybe use some other value, maybe high bits? It is a kind of 
> > > service flag, not data mapping attribute, so better to move it to high 
> > > bits (the bit before OMP_MAP_MEMBER_OF maybe?).
> > Hi @ABataev, is there any place I can find which value has been used for 
> > lower bits (like 0x800, 0x1000)?
> I rather doubt. You can try to ask @kkwli0 
We are using 0x800.  I think your current choice should be fine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79972/new/

https://reviews.llvm.org/D79972



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D75001#1922789 , @jdoerfert wrote:

> In D75001#1891284 , @Hahnfeld wrote:
>
> > In D75001#1887876 , @jdoerfert 
> > wrote:
> >
> > > I like this way better. I was hoping we could do it in our cmake only :)
> > >
> > > Give others a day or so to comment before your commit but I'm fine with 
> > > this.
> >
> >
> > Well, that doesn't really work if `openmp-commits` is only subscribed on 
> > commit. That said, the solution is a bit ugly but I don't have an 
> > alternative right now.
>
>
> What is the problem with `openmp-commits` here? I got the emails, didn't you?
>
> @kkwli0 Where are we with this?


@jdoerfert  In terms of the scope of this issue, it is done.  It is to ignore 
the warning in order to avoid build blockage in the future when newer CUDA 
toolkit is available and installed on the build system.  Another related issue 
that blocked the other part of the tests (related to python binding) was 
resolved in https://reviews.llvm.org/D76030.  As far as I know, the remaining 
one (not quite an issue, it is by design) is warning issued when 
-fopenm-targets=nvptx* is specified, users can suppress it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75001/new/

https://reviews.llvm.org/D75001



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D75001#1891966 , @tra wrote:

> In D75001#1891861 , @kkwli0 wrote:
>
> > @tra Will it also include -fopenmp-targets=nvptx64-nvidia-cuda?
>
>
> If you're asking whether the warning will be disabled for OpenMP, then no. 
> This OpenMP target appears to rely on CUDA, and I think all the reasons for 
> the warning existence do still apply.
>  If you're asking about the workaround, it would only work for non-CUDA 
> compilations that don't really need CUDA SDK, so the answer is probably 'no' 
> as well as you will need a valid CUDA path.


Thanks.  I meant the former.  This can also solve the other issue mentioned in 
D74571 .


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75001/new/

https://reviews.llvm.org/D75001



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D75001#1891742 , @tra wrote:

> In D75001#1891284 , @Hahnfeld wrote:
>
> > In D75001#1887876 , @jdoerfert 
> > wrote:
> >
> > > I like this way better. I was hoping we could do it in our cmake only :)
> > >
> > > Give others a day or so to comment before your commit but I'm fine with 
> > > this.
> >
> >
> > Well, that doesn't really work if `openmp-commits` is only subscribed on 
> > commit. That said, the solution is a bit ugly but I don't have an 
> > alternative right now.
> >
> > Somewhat related, that means Clang issues a warning for every compilation 
> > should there be a "unsupported" CUDA version around, even if it's not used? 
> > @tra maybe we can only issue the warning if CUDA is going to be used?
>
>
> This is a good point. It should only affect compilations done with `-x cuda`. 
> I'll fix that.
>  Short-term workaround is to specify invalid path to CUDA installation with 
> `--cuda-path=/does/not/exist`


@tra Will it also include -fopenmp-targets=nvptx64-nvidia-cuda?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75001/new/

https://reviews.llvm.org/D75001



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

> Somewhat related, that means Clang issues a warning for every compilation 
> should there be a "unsupported" CUDA version around, even if it's not used? 
> @tra maybe we can only issue the warning if CUDA is going to be used?

Some related issues were discussed in D74571 .

Another possible approach is to include `C_FLAGS` and `CXX_FLAGS` in the test.  
Users configure the cmake with `-DCMAKE_CXX_FLAGS=-Wno-unknown-cuda-version 
-DCMAKE_C_FLAGS=-Wno-unknown-cuda-version` to get around the issues.  So I 
think this approach can avoid any similar issue blocking the libomp build in 
the feature.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75001/new/

https://reviews.llvm.org/D75001



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe16e267bb6ee: [OpenMP][cmake] ignore warning on unknown CUDA 
version (authored by kkwli0).
Herald added a project: OpenMP.
Herald added a subscriber: openmp-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75001/new/

https://reviews.llvm.org/D75001

Files:
  openmp/runtime/cmake/LibompCheckLinkerFlag.cmake


Index: openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
===
--- openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
+++ openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
@@ -38,7 +38,8 @@
 
   if(try_compile_result)
 foreach(regex IN LISTS failed_regexes)
-  if("${OUTPUT}" MATCHES ${regex})
+  # Ignore the warning about the newer or unknown CUDA version.
+  if(("${OUTPUT}" MATCHES ${regex}) AND NOT ("${OUTPUT}" MATCHES "Unknown 
CUDA version"))
 set(retval FALSE)
   endif()
 endforeach()


Index: openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
===
--- openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
+++ openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
@@ -38,7 +38,8 @@
 
   if(try_compile_result)
 foreach(regex IN LISTS failed_regexes)
-  if("${OUTPUT}" MATCHES ${regex})
+  # Ignore the warning about the newer or unknown CUDA version.
+  if(("${OUTPUT}" MATCHES ${regex}) AND NOT ("${OUTPUT}" MATCHES "Unknown CUDA version"))
 set(retval FALSE)
   endif()
 endforeach()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75001: [OpenMP][cmake] ignore warning on unknown CUDA version

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: tra, ABataev, JonChesterfield, jdoerfert, ye-luo.
Herald added subscribers: guansong, mgorny.

With CUDA 10.2 installed on the system, the compiler issues a warning about 
unknown CUDA version.  The warning message makes the 
`LIBOMP_HAVE_VERSION_SCRIPT_FLAG` test returns false.  As a result, building 
libomp fails.

  
/opt/rh/devtoolset-8/root/usr/lib/gcc/ppc64le-redhat-linux/8/../../../../bin/ld:
 ../../../../lib/libomp.so: version node not found for symbol 
omp_get_num_places_@@VERSION
  
/opt/rh/devtoolset-8/root/usr/lib/gcc/ppc64le-redhat-linux/8/../../../../bin/ld:
 failed to set dynamic section sizes: Bad value

This patch is to make the `libomp_check_linker_flag` function called in the 
`LIBOMP_HAVE_VERSION_SCRIPT_FLAG` test more tolerable with the warning message.


https://reviews.llvm.org/D75001

Files:
  openmp/runtime/cmake/LibompCheckLinkerFlag.cmake


Index: openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
===
--- openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
+++ openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
@@ -38,7 +38,8 @@
 
   if(try_compile_result)
 foreach(regex IN LISTS failed_regexes)
-  if("${OUTPUT}" MATCHES ${regex})
+  # Ignore the warning about the newer or unknown CUDA version.
+  if(("${OUTPUT}" MATCHES ${regex}) AND NOT ("${OUTPUT}" MATCHES "Unknown 
CUDA version"))
 set(retval FALSE)
   endif()
 endforeach()


Index: openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
===
--- openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
+++ openmp/runtime/cmake/LibompCheckLinkerFlag.cmake
@@ -38,7 +38,8 @@
 
   if(try_compile_result)
 foreach(regex IN LISTS failed_regexes)
-  if("${OUTPUT}" MATCHES ${regex})
+  # Ignore the warning about the newer or unknown CUDA version.
+  if(("${OUTPUT}" MATCHES ${regex}) AND NOT ("${OUTPUT}" MATCHES "Unknown CUDA version"))
 set(retval FALSE)
   endif()
 endforeach()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74941: [OpenMP] `omp begin/end declare variant` - part 1, parsing

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Since it is a TR8 feature, should we have this guarded by `-fopenmp-version=`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74941/new/

https://reviews.llvm.org/D74941



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

So an alternative is to:

- patch `openmp/runtime/cmake/LibompCheckLinkerFlag.cmake` to make the 
`libomp_check_linker_flag` function to ignore the "Unknown CUDA version" 
warning,  AND
- ask users to build with `-DCMAKE_CXX_FLAGS=-Wno-unknown-cuda-version 
-DCMAKE_C_FLAGS=-Wno-unknown-cuda-version` to get around the `C_SUPPORTS_FPIC` 
test in `cmake/modules/HandleLLVMOptions.cmake` if the system has CUDA10.2 
installed.




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74941: [OpenMP] `omp begin/end declare variant` - part 1, parsing

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1251
   "expected '#pragma omp end declare target'">;
+def err_expected_end_declare_target_or_variant : Error<
+  "expected '#pragma omp end declare %select{target|variant}0'">;

Can we merge it with err_expected_end_declare_target?



Comment at: clang/lib/Parse/ParseOpenMP.cpp:1790
+ASTContext &ASTCtx = Actions.getASTContext();
+TI.getAsVariantMatchInfo(ASTCtx, VMI, /* DeviseSetOnly */ true);
+OMPContext OMPCtx(ASTCtx.getLangOpts().OpenMPIsDevice,

DeviseSetOnly -> DeviceSetOnly


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74941/new/

https://reviews.llvm.org/D74941



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Summary

- In order to avoid the bug in PR44587 
, one needs to build with >9.0.
- With CUDA toolkit 10.2, building the trunk will fail because 10.0.0 does not 
support it yet.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

> I am not sure I understand. Do we need to modify stuff outside of `/openmp`? 
> I was hoping it is our CMake that can be adjusted to make this work as 
> described earlier. TBH, he warning is even not my biggest problem. As long as 
> we get a libomptarget.bc we should be fine.

@jdoerfert  Yes.  The warning message affects the outcome of another test in 
cmake.  With the approach of ignoring the warning message, we need to modify 
stuff outside of `/openmp`.  For me, I don't mind to have the warning messages 
all over the places.  The problem we have here is unable to build libomp.so.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

It turns out that having the warning message also affects the C_SUPPORTS_FPIC 
test in `cmake/modules/HandleLLVMOptions.cmake`.  As a result, `cmake` thinks 
that `-fPIC` is not supported.  Eventually, it leads to error in 
`libclang-cpp.so`.

  ../../lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: In 
function `clang::CodeGen::CodeGenModule::~CodeGenModule()':
  CodeGenModule.cpp:(.text+0x1134): call to `std::_Rb_tree >, std::_Select1st > >, std::less, 
std::allocator > > 
>::_M_erase(std::_Rb_tree_node > >*)' lacks nop, can't restore toc; 
recompile with -fPIC
  ...

I don't think it is a good idea to modify this test which explicitly specifies 
-Werror.

Any other ideas are definitely welcome!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Thanks for all the comments.  It makes sense to keep the warning there before 
any ptx65 features are added.  The warning should also apply to both the CUDA 
and OpenMP compile paths.  As a result, I will pursue to ignore the warning in 
the build of libomp (i.e. libomp_check_linker_flag function in 
LibompCheckLinkerFlag.cmake).  I think it is less pervasive and also can avoid 
similar occurrence when a new version of CUDA toolkit is available.

Comments?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D74571#1874950 , @jdoerfert wrote:

> > in order to avoid bug 44587 which requires >9.0.1 to be the build compiler?
>
> Do we already require CUDA 10 as part of the libomptarget cmake (with a nice 
> message) to avoid the errors you've seen? We for sure need to.


This is a good idea but probably done in a separate patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D74571#1874947 , @JonChesterfield 
wrote:

> Do the in tree tests all pass with the 10.2 toolchain? That's not exactly the 
> same as whether it works but is the closest approximation we have available.
>
> Assuming yes, this patch seems uncontroversial.


Yes, in tree tests pass with 10.2.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74571/new/

https://reviews.llvm.org/D74571



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74571: [OpenMP][CUDA] Add CUDA 10.2 support

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: jdoerfert, ABataev, JonChesterfield, tra.
Herald added a subscriber: guansong.
kkwli0 edited the summary of this revision.

This patch is to add CUDA 10.2 support.  It essentially removes the warning 
message regarding the CUDA 10.2 toolkit not being supported.  This warning 
causes libomp not being built as the LIBOMP_HAVE_VERSION_SCRIPT_FLAG test 
returns false.

Question to reviewers and others:
Do we also want to put this patch to 10.0.0 RC2 in order to avoid bug 44587 
 which requires >9.0.1 to be the 
build compiler?


https://reviews.llvm.org/D74571

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -634,6 +634,7 @@
   // back-end.
   const char *PtxFeature = nullptr;
   switch(CudaInstallation.version()) {
+case CudaVersion::CUDA_102:
 case CudaVersion::CUDA_101:
   PtxFeature = "+ptx64";
   break;
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -28,6 +28,8 @@
 return "10.0";
   case CudaVersion::CUDA_101:
 return "10.1";
+  case CudaVersion::CUDA_102:
+return "10.2";
   }
   llvm_unreachable("invalid enum");
 }
@@ -42,6 +44,7 @@
   .Case("9.2", CudaVersion::CUDA_92)
   .Case("10.0", CudaVersion::CUDA_100)
   .Case("10.1", CudaVersion::CUDA_101)
+  .Case("10.2", CudaVersion::CUDA_102)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -382,6 +385,8 @@
 return CudaVersion::CUDA_100;
   case 101:
 return CudaVersion::CUDA_101;
+  case 102:
+return CudaVersion::CUDA_102;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -27,7 +27,8 @@
   CUDA_92,
   CUDA_100,
   CUDA_101,
-  LATEST = CUDA_101,
+  CUDA_102,
+  LATEST = CUDA_102,
 };
 const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -634,6 +634,7 @@
   // back-end.
   const char *PtxFeature = nullptr;
   switch(CudaInstallation.version()) {
+case CudaVersion::CUDA_102:
 case CudaVersion::CUDA_101:
   PtxFeature = "+ptx64";
   break;
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -28,6 +28,8 @@
 return "10.0";
   case CudaVersion::CUDA_101:
 return "10.1";
+  case CudaVersion::CUDA_102:
+return "10.2";
   }
   llvm_unreachable("invalid enum");
 }
@@ -42,6 +44,7 @@
   .Case("9.2", CudaVersion::CUDA_92)
   .Case("10.0", CudaVersion::CUDA_100)
   .Case("10.1", CudaVersion::CUDA_101)
+  .Case("10.2", CudaVersion::CUDA_102)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -382,6 +385,8 @@
 return CudaVersion::CUDA_100;
   case 101:
 return CudaVersion::CUDA_101;
+  case 102:
+return CudaVersion::CUDA_102;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -27,7 +27,8 @@
   CUDA_92,
   CUDA_100,
   CUDA_101,
-  LATEST = CUDA_101,
+  CUDA_102,
+  LATEST = CUDA_102,
 };
 const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGac430336318a: [OpenMP] [DOCS] Update OMP5.0 feature status 
table [NFC] (authored by kkwli0).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -191,9 +191,11 @@
 
+--+--+--+---+
 | device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :part:`partial`  | 
  |
 
+--+--+--+---+
-| device extension | clause: unified_address, 
unified_shared_memory   | :good:`done` | D52625,D52359  
   |
+| device extension | clause: unified_shared_memory 
   | :good:`done` | D52625,D52359   
  |
++--+--+--+---+
+| device extension | clause: unified_address   
   | :part:`partial`  | 
  |
 
+--+--+--+---+
 | device extension | clause: reverse_offload   
   | :none:`unclaimed parts`  | D52780  
  |
 
+--+--+--+---+
@@ -207,12 +209,14 @@
 
+--+--+--+---+
 | device extension | clause: use_device_addr for target data   
   | :part:`worked on`| 
  |
 
+--+--+--+---+
-| device extension | map(replicate) or map(local) when requires 
unified_shared_me | :part:`worked on`| D55719,D55892
 |
+| device extension | support close modifier on map clause  
   | :good:`done` | D55719,D55892   
  |
 
+--+--+--+---+
 | device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :part:`worked on`| 
  |
 
+--+--

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:216
 
+--+--+--+---+
+| device extension | pointer attachment
   | :none:`unclaimed`| 
  |
++--+--+--+---+

ABataev wrote:
> kkwli0 wrote:
> > jdoerfert wrote:
> > > ABataev wrote:
> > > > Is this for Fortran?
> > > No also C/C++.
> > Yep, it is not Fortran only.  We clarify some pointer attachment behavior 
> > in 5.0.
> Could add a reference to the section in the standard?
I am not sure if this and another feature should be treated as special cases.  
If it is not, we will need to add references for all the features.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 242166.
kkwli0 added a comment.

Change `requires unified_address` status to partial.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -191,9 +191,11 @@
 
+--+--+--+---+
 | device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :part:`partial`  | 
  |
 
+--+--+--+---+
-| device extension | clause: unified_address, 
unified_shared_memory   | :good:`done` | D52625,D52359  
   |
+| device extension | clause: unified_shared_memory 
   | :good:`done` | D52625,D52359   
  |
++--+--+--+---+
+| device extension | clause: unified_address   
   | :part:`partial`  | 
  |
 
+--+--+--+---+
 | device extension | clause: reverse_offload   
   | :none:`unclaimed parts`  | D52780  
  |
 
+--+--+--+---+
@@ -207,12 +209,14 @@
 
+--+--+--+---+
 | device extension | clause: use_device_addr for target data   
   | :part:`worked on`| 
  |
 
+--+--+--+---+
-| device extension | map(replicate) or map(local) when requires 
unified_shared_me | :part:`worked on`| D55719,D55892
 |
+| device extension | support close modifier on map clause  
   | :good:`done` | D55719,D55892   
  |
 
+--+--+--+---+
 | device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :part:`worked on`| 
  |
 
+--+--+--+-

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Ping


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 239719.
kkwli0 marked 2 inline comments as done.
kkwli0 added a comment.
Herald added a subscriber: jfb.

Address review comments and rebase.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -191,7 +191,7 @@
 
+--+--+--+---+
 | device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :part:`partial`  | 
  |
 
+--+--+--+---+
 | device extension | clause: unified_address, 
unified_shared_memory   | :good:`done` | D52625,D52359  
   |
 
+--+--+--+---+
@@ -207,12 +207,14 @@
 
+--+--+--+---+
 | device extension | clause: use_device_addr for target data   
   | :part:`worked on`| 
  |
 
+--+--+--+---+
-| device extension | map(replicate) or map(local) when requires 
unified_shared_me | :part:`worked on`| D55719,D55892
 |
+| device extension | support close modifier on map clause  
   | :good:`done` | D55719,D55892   
  |
 
+--+--+--+---+
 | device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :part:`worked on`| 
  |
 
+--+--+--+---+
+| device extension | pointer attachment
   | :none:`unclaimed`| 
  |
++--+--+--+---+
 | atomic extension | hints for the atomic construct
   | :part:`worked on`| D51233  
  |
 
+--+--+--+---+
 | base language| C11 support   
   | :none:`unclaimed`

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 13 inline comments as done.
kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:216
 
+--+--+--+---+
+| device extension | pointer attachment
   | :none:`unclaimed`| 
  |
++--+--+--+---+

jdoerfert wrote:
> ABataev wrote:
> > Is this for Fortran?
> No also C/C++.
Yep, it is not Fortran only.  We clarify some pointer attachment behavior in 
5.0.



Comment at: clang/docs/OpenMPSupport.rst:240
++--+--+--+---+
+| misc extension   | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+

jdoerfert wrote:
> ABataev wrote:
> > kkwli0 wrote:
> > > ABataev wrote:
> > > > What is this?
> > > This is a clarification. The spec add restrictions to declare new type on 
> > > iterators, declare reduction and declare mapper [49:11; 308:17; 327:26]
> > Would be good to put these links to the doc to make it clear
> > Would be good to put these links to the doc to make it clear
> 
> Agreed. We have the HTML version of the standard online so we can do this 
> "easily" but it will cost someone time and require to change the table 
> layout. Let's postpone it for now until someone find some spare minutes.
Yes, it involves a significant change in the table if we include the 
corresponding text change in the table.  In some cases, it is not clear from 
the original tickets.  I think it is better to leave it as-is.  If change the 
description can help, I welcome any suggestions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:242
 
+--+--+--+---+
-| misc extensions  | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
+| memory model extension   | memory model update   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+

ABataev wrote:
> What kind of memory model update?
We add five _memory-order-clause_s in the atomic directive - `seq_cst`, 
`acq_rel`, `release`, `acquire` and `relaxed` to support the memory model.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:194
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :good:`done` | 
  |
 
+--+--+--+---+

jdoerfert wrote:
> ABataev wrote:
> > We have support only for unified memory, so must be `partial`
> Let's keep the explicit ` (unified shared memory) -> done ` line and add one 
> for the others as not done.
@abataev It makes sense to make it `partial`.

@jdoerfert  Keeping that line can be confusing.  Line 196 is clear to indicate 
that the unified_address and unified_shared_memory parts of the requires 
directive is done.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:240
++--+--+--+---+
+| misc extension   | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+

ABataev wrote:
> What is this?
This is a clarification. The spec add restrictions to declare new type on 
iterators, declare reduction and declare mapper [49:11; 308:17; 327:26]


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72901/new/

https://reviews.llvm.org/D72901



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: ABataev, RaviNarayanaswamy, jdoerfert.
Herald added a subscriber: guansong.

Add missing OMP5.0 features.


https://reviews.llvm.org/D72901

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -191,7 +191,7 @@
 
+--+--+--+---+
 | device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :good:`done` | 
  |
 
+--+--+--+---+
 | device extension | clause: unified_address, 
unified_shared_memory   | :good:`done` | D52625,D52359  
   |
 
+--+--+--+---+
@@ -207,12 +207,14 @@
 
+--+--+--+---+
 | device extension | clause: use_device_addr for target data   
   | :part:`worked on`| 
  |
 
+--+--+--+---+
-| device extension | map(replicate) or map(local) when requires 
unified_shared_me | :part:`worked on`| D55719,D55892
 |
+| device extension | map(local) when requires 
unified_shared_memory   | :part:`worked on`| D55719,D55892  
   |
 
+--+--+--+---+
 | device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :part:`worked on`| 
  |
 
+--+--+--+---+
+| device extension | pointer attachment
   | :none:`unclaimed`| 
  |
++--+--+--+---+
 | atomic extension | hints for the atomic construct
   | :part:`worked on`| D51233  
  |
 
+--+--+--+---+
 | base language| C11 support   
   | :none:`unclaimed`| 
  |
@@ -229,11

[PATCH] D71969: [OpenMP] diagnose zero-length array section in the depend clause

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG427ffa2cdbbc: [OpenMP] diagnose zero-length array section in 
the depend clause (authored by kkwli0).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71969/new/

https://reviews.llvm.org/D71969

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_depend_messages.cpp
  clang/test/OpenMP/target_enter_data_depend_messages.cpp
  clang/test/OpenMP/target_exit_data_depend_messages.cpp
  clang/test/OpenMP/target_parallel_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_messages.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_messages.cpp
  clang/test/OpenMP/target_update_depend_messages.cpp
  clang/test/OpenMP/task_depend_messages.cpp

Index: clang/test/OpenMP/task_depend_messages.cpp
===
--- clang/test/OpenMP/task_depend_messages.cpp
+++ clang/test/OpenMP/task_depend_messages.cpp
@@ -45,7 +45,7 @@
   #pragma omp task depend (in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp task depend (in : argv[-1:0])
+  #pragma omp task depend (in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp task depend (in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp task depend (in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp task depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
Index: clang/test/OpenMP/target_update_depend_messages.cpp
===
--- clang/test/OpenMP/target_update_depend_messages.cpp
+++ clang/test/OpenMP/target_update_depend_messages.cpp
@@ -15,7 +15,6 @@
   public:
 int operator[](int index) { return 0; }
 };
-
 template 
 int tmain(T argc, S **argv, R *env[]) {
   vector vec;
@@ -52,7 +51,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp target update to(z) depend(in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp target update to(z) depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
@@ -64,7 +63,6 @@
 
   return 0;
 }
-
 int main(int argc, char **argv, char *env[]) {
   vector vec;
   typedef float V __attribute__((vector_size(16)));
@@ -100,7 +98,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:])

[PATCH] D71969: [OpenMP] diagnose zero-length array section in the depend clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 235894.
kkwli0 added a comment.

Update based on suggestion to simply the check and rebase.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71969/new/

https://reviews.llvm.org/D71969

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_depend_messages.cpp
  clang/test/OpenMP/target_enter_data_depend_messages.cpp
  clang/test/OpenMP/target_exit_data_depend_messages.cpp
  clang/test/OpenMP/target_parallel_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_messages.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_messages.cpp
  clang/test/OpenMP/target_update_depend_messages.cpp
  clang/test/OpenMP/task_depend_messages.cpp

Index: clang/test/OpenMP/task_depend_messages.cpp
===
--- clang/test/OpenMP/task_depend_messages.cpp
+++ clang/test/OpenMP/task_depend_messages.cpp
@@ -45,7 +45,7 @@
   #pragma omp task depend (in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp task depend (in : argv[-1:0])
+  #pragma omp task depend (in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp task depend (in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp task depend (in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp task depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
Index: clang/test/OpenMP/target_update_depend_messages.cpp
===
--- clang/test/OpenMP/target_update_depend_messages.cpp
+++ clang/test/OpenMP/target_update_depend_messages.cpp
@@ -15,7 +15,6 @@
   public:
 int operator[](int index) { return 0; }
 };
-
 template 
 int tmain(T argc, S **argv, R *env[]) {
   vector vec;
@@ -52,7 +51,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp target update to(z) depend(in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp target update to(z) depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
@@ -64,7 +63,6 @@
 
   return 0;
 }
-
 int main(int argc, char **argv, char *env[]) {
   vector vec;
   typedef float V __attribute__((vector_size(16)));
@@ -100,7 +98,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp ta

[PATCH] D71969: [OpenMP] diagnose zero-length array section in the depend clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D71969#1798224 , @jdoerfert wrote:

> Is there a reason not to put this check right next to the one that issues 
> `err_omp_section_length_negative`. SemaExpr.cpp +4668


It is a good idea to group the checking together however this check is specific 
for the depend clause.  The map clause allows the zero-length array section.  
Isn't it better to keep it in ActOnOpenMPDependClause?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71969/new/

https://reviews.llvm.org/D71969



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71969: [OpenMP] diagnose zero-length array section in the depend clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added a reviewer: ABataev.
Herald added a subscriber: guansong.
Herald added a reviewer: jdoerfert.

The OpenMP specification disallows having zero-length array sections in the 
depend clause (OpenMP 5.0 2.17.11).


https://reviews.llvm.org/D71969

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_depend_messages.cpp
  clang/test/OpenMP/target_enter_data_depend_messages.cpp
  clang/test/OpenMP/target_exit_data_depend_messages.cpp
  clang/test/OpenMP/target_parallel_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_depend_messages.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_messages.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_messages.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_messages.cpp
  clang/test/OpenMP/target_update_depend_messages.cpp
  clang/test/OpenMP/task_depend_messages.cpp

Index: clang/test/OpenMP/task_depend_messages.cpp
===
--- clang/test/OpenMP/task_depend_messages.cpp
+++ clang/test/OpenMP/task_depend_messages.cpp
@@ -45,7 +45,7 @@
   #pragma omp task depend (in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp task depend (in : argv[-1:0])
+  #pragma omp task depend (in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp task depend (in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp task depend (in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp task depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
Index: clang/test/OpenMP/target_update_depend_messages.cpp
===
--- clang/test/OpenMP/target_update_depend_messages.cpp
+++ clang/test/OpenMP/target_update_depend_messages.cpp
@@ -15,7 +15,6 @@
   public:
 int operator[](int index) { return 0; }
 };
-
 template 
 int tmain(T argc, S **argv, R *env[]) {
   vector vec;
@@ -52,7 +51,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp target update to(z) depend(in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp target update to(z) depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
@@ -64,7 +63,6 @@
 
   return 0;
 }
-
 int main(int argc, char **argv, char *env[]) {
   vector vec;
   typedef float V __attribute__((vector_size(16)));
@@ -100,7 +98,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0])
+  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{zero-length array section is not allowed in 'depend' clause}}
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred becau

[PATCH] D70608: [OPENMP] [DOCS] correct status for use_device_addr clause

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0c7a1c0cfc2a: [OPENMP] [DOCS] correct status for 
use_device_addr clause (authored by kkwli0).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70608/new/

https://reviews.llvm.org/D70608

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -205,7 +205,7 @@
 
+--+--+--+---+
 | device extension | mapping lambda expression 
   | :good:`done` | D51107  
  |
 
+--+--+--+---+
-| device extension | clause: use_device_addr for target data   
   | :good:`done` | 
  |
+| device extension | clause: use_device_addr for target data   
   | :part:`worked on`| 
  |
 
+--+--+--+---+
 | device extension | map(replicate) or map(local) when requires 
unified_shared_me | :part:`worked on`| D55719,D55892
 |
 
+--+--+--+---+


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -205,7 +205,7 @@
 +--+--+--+---+
 | device extension | mapping lambda expression| :good:`done` | D51107|
 +--+--+--+---+
-| device extension | clause: use_device_addr for target data  | :good:`done` |   |
+| device extension | clause: use_device_addr for target data  | :part:`worked on`|   |
 +--+--+--+---+
 | device extension | map(replicate) or map(local) when requires unified_shared_me | :part:`worked on`| D55719,D55892 |
 +--+--+--+---+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69909: [OPENMP] [DOCS] fix section formatting issues [NFC]

[Kelvin Li via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9f10cc2d124c: [OPENMP] [DOCS] fix section formatting issues 
[NFC] (authored by kkwli0).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69909/new/

https://reviews.llvm.org/D69909

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -13,9 +13,8 @@
 .. contents::
:local:
 
-==
 OpenMP Support
-==
+==
 
 Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
 PPC64[LE] and has `basic support for Cuda devices`_.
@@ -30,7 +29,7 @@
 For the list of supported features from OpenMP 5.0 see `OpenMP implementation 
details`_.
 
 General improvements
-
+
 - New collapse clause scheme to avoid expensive remainder operations.
   Compute loop index variables after collapsing a loop nest via the
   collapse clause by replacing the expensive remainder operation with
@@ -47,6 +46,13 @@
 - Simplified SPMD code generation for `distribute parallel for` when
   the new default schedules are applicable.
 
+- When using the collapse clause on a loop nest the default behavior
+  is to automatically extend the representation of the loop counter to
+  64 bits for the cases where the sizes of the collapsed loops are not
+  known at compile time. To prevent this conservative choice and use
+  at most 32 bits, compile your program with the
+  `-fopenmp-optimistic-collapse`.
+
 .. _basic support for Cuda devices:
 
 Cuda devices support
@@ -77,15 +83,6 @@
 between the threads and it is user responsibility to share the required data
 between the threads in the parallel regions.
 
-Collapsed loop nest counter

-
-When using the collapse clause on a loop nest the default behavior is to
-automatically extend the representation of the loop counter to 64 bits for
-the cases where the sizes of the collapsed loops are not known at compile
-time. To prevent this conservative choice and use at most 32 bits,
-compile your program with the `-fopenmp-optimistic-collapse`.
-
 
 Features not supported or with limited support for Cuda devices
 ---
@@ -112,7 +109,7 @@
 .. _OpenMP implementation details:
 
 OpenMP 5.0 Implementation Details
--
+=
 
 The following table provides a quick overview over various OpenMP 5.0 features
 and their implementation status. Please contact *openmp-dev* at


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -13,9 +13,8 @@
 .. contents::
:local:
 
-==
 OpenMP Support
-==
+==
 
 Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
 PPC64[LE] and has `basic support for Cuda devices`_.
@@ -30,7 +29,7 @@
 For the list of supported features from OpenMP 5.0 see `OpenMP implementation details`_.
 
 General improvements
-
+
 - New collapse clause scheme to avoid expensive remainder operations.
   Compute loop index variables after collapsing a loop nest via the
   collapse clause by replacing the expensive remainder operation with
@@ -47,6 +46,13 @@
 - Simplified SPMD code generation for `distribute parallel for` when
   the new default schedules are applicable.
 
+- When using the collapse clause on a loop nest the default behavior
+  is to automatically extend the representation of the loop counter to
+  64 bits for the cases where the sizes of the collapsed loops are not
+  known at compile time. To prevent this conservative choice and use
+  at most 32 bits, compile your program with the
+  `-fopenmp-optimistic-collapse`.
+
 .. _basic support for Cuda devices:
 
 Cuda devices support
@@ -77,15 +83,6 @@
 between the threads and it is user responsibility to share the required data
 between the threads in the parallel regions.
 
-Collapsed loop nest counter

-
-When using the collapse clause on a loop nest the default behavior is to
-automatically extend the representation of the loop counter to 64 bits for
-the cases where the sizes of the collapsed loops are not known at compile
-time. To prevent this conservative choice and use at most 32 bits,
-compile your program with the `-fopenmp-optimistic-collapse`.
-
 
 Features not supported or with limited support for Cuda devices
 ---
@@ -112,7 +109,7 @@
 .. _OpenMP implementation details:
 
 OpenMP 5.0 Implementation Details
---

[PATCH] D64375: [OpenMP][Docs] Provide implementation status details

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:204
++--+--+--++
+| device extension | clause: device_type   
   | :part:`worked on`| 
   |
++--+--+--++

ABataev wrote:
> jdoerfert wrote:
> > ABataev wrote:
> > > This feature is implemented already
> > If we wait longer, we can always update this patch. Maybe we should 
> > upstream it and update it online.
> > 
> > @RaviNarayanaswamy @kkwli0 @ABataev 
> Add the latest info and commit it.
Agreed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64375/new/

https://reviews.llvm.org/D64375



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65835: [OpenMP] Fix map/is_device_ptr with DSA on combined directive

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D65835#1623883 , @hfinkel wrote:

> In D65835#1623814 , @hfinkel wrote:
>
> > In D65835#1623772 , @ABataev wrote:
> >
> > > In D65835#1623756 , @kkwli0 
> > > wrote:
> > >
> > > > In D65835#1622042 , @ABataev 
> > > > wrote:
> > > >
> > > > > > I want to be sure we're on the same page: For OpenMP 5.0, should we 
> > > > > > allow is_device_ptr with the private clauses?
> > > > >
> > > > > Yes, since it is allowed by the standard.
> > > >
> > > >
> > > > Umm ... I probably missed some earlier discussions!  What would be the 
> > > > behavior of the following code?
> > > >
> > > >   p = omp_target_alloc(...);
> > > >   #pragma omp target private(p) is_device_ptr(p)
> > > > p[...] = ...;   // crash or not?
> > > >
> > >
> > >
> > > It must crush, I assume. The main problem is that this construct is 
> > > allowed by the standard.
> >
> >
> > Yep. We should add a warning message for it.
>
>
> Upon further reflection, this is not clearly allowed by the standard. My 
> experience is that, when reading standards, sometimes things are disallowed 
> by contradiction (i.e., the standard does not define some behavior, and what 
> the standard does say that's relevant is self contradictory). In this case, 
> 2.19.3 says that list items which are privatized (and which are used) undergo 
> replacement (with new items created as specified) while 2.12.5 says that "The 
> is_device_ptr clause is used to indicate that a list item is a device pointer 
> already in the device data environment and that it should be used directly." 
> A given list item cannot simultaneously be "used directly" (2.12.5) and also 
> undergo replacement: "Inside the construct, all references to the original 
> list item are replaced by references to a new list item received by the task 
> or SIMD lane" (2.19.3). Thus, it may be disallowed.


That is what I thought.  Specifying these two clauses on the target construct 
creates ambiguity on which p it referred to inside the construct.  The private 
p or the pointer p that stores the device address?  I will work with the 
committee to fix the spec.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65835/new/

https://reviews.llvm.org/D65835



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65835: [OpenMP] Fix map/is_device_ptr with DSA on combined directive

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D65835#1622042 , @ABataev wrote:

> > I want to be sure we're on the same page: For OpenMP 5.0, should we allow 
> > is_device_ptr with the private clauses?
>
> Yes, since it is allowed by the standard.


Umm ... I probably missed some earlier discussions!  What would be the behavior 
of the following code?

  p = omp_target_alloc(...);
  #pragma omp target private(p) is_device_ptr(p)
p[...] = ...;   // crash or not?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65835/new/

https://reviews.llvm.org/D65835



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Looks fine to me.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D65341#1604562 , @kkwli0 wrote:

> In D65341#1604561 , @gtbercea wrote:
>
> > In D65341#1604440 , @ABataev wrote:
> >
> > > In D65341#1604411 , @Hahnfeld 
> > > wrote:
> > >
> > > > There's already D55892  with a better 
> > > > set of tests, including `target enter data` / `target exit data`.
> > >
> > >
> > > Better to merge those two patches into one.
> >
> >
> > How would you like me to proceed? It looks like the other patch has been 
> > sitting there approved for many many months.
>
>
> Yes, the patch has been waiting for the runtime implementation first and then 
> commit.


I am not sure if it is easier to rebase D55892 
 and merge this patch to D55892 
.  I am okay to go either way.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65341: [OpenMP] Add support for close map modifier in Clang

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D65341#1604561 , @gtbercea wrote:

> In D65341#1604440 , @ABataev wrote:
>
> > In D65341#1604411 , @Hahnfeld 
> > wrote:
> >
> > > There's already D55892  with a better 
> > > set of tests, including `target enter data` / `target exit data`.
> >
> >
> > Better to merge those two patches into one.
>
>
> How would you like me to proceed? It looks like the other patch has been 
> sitting there approved for many many months.


Yes, the patch has been waiting for the runtime implementation first and then 
commit.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65341/new/

https://reviews.llvm.org/D65341



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64375: [OpenMP][Docs] Provide implementation status details

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:198
++--+--+--++
+| device extension | OMP_TARGET_FALLBACK env variable  
   | :part:`worked on`| D50522  
   |
++--+--+--++

Change OMP_TARGET_FALLBACK to OMP_TARGET_OFFLOAD which is in the spec.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64375/new/

https://reviews.llvm.org/D64375



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64375: [OpenMP][Docs] Provide implementation status details

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:184
++--+--+--++
+| task extension   | parallell master taskloop 
   | :none:`unclaimed`| 
   |
++--+--+--++

parallell -> parallel



Comment at: clang/docs/OpenMPSupport.rst:188
++--+--+--++
+| task extension   | parallell master taskloop simd
   | :none:`unclaimed`| 
   |
++--+--+--++

parallell -> parallel


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64375/new/

https://reviews.llvm.org/D64375



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64375: [OpenMP][Docs] Provide implementation status details

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:205
++--+--+--++
+| device extension | clause: device_type   
   | claimed  ||
++--+--+--++

ABataev wrote:
> Can't find this in the standard.
Section 2.12.7



Comment at: clang/docs/OpenMPSupport.rst:233
++--+--+--++
+| device extension | mapping lambda expression 
   | claimed  | D51107 |
++--+--+--++

ABataev wrote:
> Done
Do we support the behavior in 318:7-14?



Comment at: clang/docs/OpenMPSupport.rst:237
++--+--+--++
+| device extension | map(replicate) or map(local) when requires 
unified_shared_me | done | D55719,D55892  |
++--+--+--++

ABataev wrote:
> Not sure 100%, but seems to me it is not done.
I think we still need the codegen patch and I am not sure about the runtime 
part.



Comment at: clang/docs/OpenMPSupport.rst:243
++--+--+--++
+| atomic extension | hints for the atomic construct
   | done | D51233 |
++--+--+--++

ABataev wrote:
> This is just the runtime part, the compiler does not support this
Since it is a hint according to the specification, I guess it is up to us 
whether we want to declare this feature done or not.  If we do that, we should 
mention it in the limitation section.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64375/new/

https://reviews.llvm.org/D64375



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58504: [OpenCL][8.0.0 Release] Notes for OpenCL

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: docs/ReleaseNotes.rst:14
 
-This document contains the release notes for the Clang C/C++/Objective-C
+This document contains the release notes for the Clang C/C++/Objective-C/OpenCL
 frontend, part of the LLVM Compiler Infrastructure, release 8.0.0. Here we

Anastasia wrote:
> ABataev wrote:
> > Anastasia wrote:
> > > Anastasia wrote:
> > > > @hans  I am not sure if it's best to list all languages supported (i.e. 
> > > > OpenMP, Renderscript, CUDA are still missing) or alternatively we could 
> > > > change to something like - Clang C language family frontend? The latter 
> > > > one is taken from the main page: https://clang.llvm.org/. Although, 
> > > > OpenMP is missing on the main page.
> > > @ABataev should the main page be updated to list OpenMP explicitly?
> > Well, generally speaking, OpenMP is not a programming language, it is an 
> > API, i.e. just an extension for C/C++/Fortran. Not sure that it must be in 
> > the list of the actual languages.
> Ok, then I guess it will be ok to leave it out in this update to the release 
> notes too!
I agree with Alexey.  OpenMP is an API specification not quite a language yet.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58504/new/

https://reviews.llvm.org/D58504



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58243: [OPENMP] Delay emission of the asm target-specific error messages.

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

The change looks okay to me.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58243/new/

https://reviews.llvm.org/D58243



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: include/clang/AST/OpenMPClause.h:4077
 
+  /// C++ nested name specifier for the assoicated user-defined mapper.
+  NestedNameSpecifierLoc MapperQualifierLoc;

assoicated -> associated



Comment at: include/clang/AST/OpenMPClause.h:4212
+assert(DMDs.size() == varlist_size() &&
+   "Unexpected amount of user-defined mappers.");
+std::copy(DMDs.begin(), DMDs.end(), getUDMapperRefs().begin());

amount -> number?



Comment at: include/clang/AST/OpenMPClause.h:4229
   /// \param MapModifiersLoc Location of map-type-modifiers.
+  /// \param UDMQualifierLoc C++ nested name specifier for the assoicated
+  /// user-defined mapper.

assoicated -> associated



Comment at: lib/Parse/ParseOpenMP.cpp:2144
+parseMapType(*this, Data);
 }
 if (Data.MapType == OMPC_MAP_unknown) {

Although it is an error situation, will we have different behavior?

```
... map(xclose, to: x)
```

Previously, it always parses both modifier and type.  After the change, the 
call of `parseMapType` is skipped.  If it `OMPC_MAP_unknown`, 
`IsMapTypeImplicit` is set.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57690: [OPENMP] issue error messages for multiple teams contructs in a target constructs

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 closed this revision.
kkwli0 added a comment.

Committed: r353186


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57690/new/

https://reviews.llvm.org/D57690



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57690: [OPENMP] issue error messages for multiple teams contructs in a target constructs

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 185125.
kkwli0 marked an inline comment as done.
kkwli0 added a comment.

Update based on review comment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57690/new/

https://reviews.llvm.org/D57690

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/nesting_of_regions.cpp


Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -4080,6 +4080,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
+  {
 ++a;   // expected-note {{statement outside teams construct here}}
 #pragma omp teams  // expected-note {{nested teams construct here}}
 ++a;
@@ -12693,6 +12700,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
+  {
 ++a;  // expected-note {{statement outside teams construct here}}
 #pragma omp teams // expected-note {{nested teams construct here}}
 ++a;
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -7067,7 +7067,9 @@
   auto I = CS->body_begin();
   while (I != CS->body_end()) {
 const auto *OED = dyn_cast(*I);
-if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind())) {
+if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind()) ||
+OMPTeamsFound) {
+
   OMPTeamsFound = false;
   break;
 }


Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -4080,6 +4080,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
+  {
 ++a;   // expected-note {{statement outside teams construct here}}
 #pragma omp teams  // expected-note {{nested teams construct here}}
 ++a;
@@ -12693,6 +12700,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
+  {
 ++a;  // expected-note {{statement outside teams construct here}}
 #pragma omp teams // expected-note {{nested teams construct here}}
 ++a;
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -7067,7 +7067,9 @@
   auto I = CS->body_begin();
   while (I != CS->body_end()) {
 const auto *OED = dyn_cast(*I);
-if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind())) {
+if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind()) ||
+OMPTeamsFound) {
+
   OMPTeamsFound = false;
   break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57690: [OPENMP] issue error messages for multiple teams contructs in a target constructs

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:7070
 const auto *OED = dyn_cast(*I);
-if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind())) {
+if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind()) ||
+(isOpenMPTeamsDirective(OED->getDirectiveKind()) &&

ABataev wrote:
> just `if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind() || 
> OMPTeamsFound)`
Yep, it simplifies the logic.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57690/new/

https://reviews.llvm.org/D57690



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57690: [OPENMP] issue error messages for multiple teams contructs in a target constructs

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added a reviewer: ABataev.
Herald added a subscriber: guansong.

The compiler does not generate any error messages if there are more than one 
teams construct inside a target constructs.

  #pragma omp target
  {
#pragma omp teams
{  ...  }
  
#pragma omp teams
{ ... }
  }

After the fix, the error messages are issued.

  teams.c:4:9: error: target construct with nested teams region contains 
statements
outside of the teams construct
  #pragma omp target
  ^
  teams.c:14:11: note: nested teams construct here
#pragma omp teams
^
  teams.c:9:11: note: directive outside teams construct here
#pragma omp teams
^
  1 error generated.


https://reviews.llvm.org/D57690

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/nesting_of_regions.cpp


Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -4080,6 +4080,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
+  {
 ++a;   // expected-note {{statement outside teams construct here}}
 #pragma omp teams  // expected-note {{nested teams construct here}}
 ++a;
@@ -12693,6 +12700,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams 
region contains statements outside of the teams construct}}
+  {
 ++a;  // expected-note {{statement outside teams construct here}}
 #pragma omp teams // expected-note {{nested teams construct here}}
 ++a;
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -7067,7 +7067,10 @@
   auto I = CS->body_begin();
   while (I != CS->body_end()) {
 const auto *OED = dyn_cast(*I);
-if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind())) {
+if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind()) ||
+(isOpenMPTeamsDirective(OED->getDirectiveKind()) &&
+ OMPTeamsFound)) {
+
   OMPTeamsFound = false;
   break;
 }


Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -4080,6 +4080,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
+  {
 ++a;   // expected-note {{statement outside teams construct here}}
 #pragma omp teams  // expected-note {{nested teams construct here}}
 ++a;
@@ -12693,6 +12700,13 @@
   }
 #pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
   {
+#pragma omp teams // expected-note {{directive outside teams construct here}}
+++a;
+#pragma omp teams // expected-note {{nested teams construct here}}
+++a;
+  }
+#pragma omp target // expected-error {{target construct with nested teams region contains statements outside of the teams construct}}
+  {
 ++a;  // expected-note {{statement outside teams construct here}}
 #pragma omp teams // expected-note {{nested teams construct here}}
 ++a;
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -7067,7 +7067,10 @@
   auto I = CS->body_begin();
   while (I != CS->body_end()) {
 const auto *OED = dyn_cast(*I);
-if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind())) {
+if (!OED || !isOpenMPTeamsDirective(OED->getDirectiveKind()) ||
+(isOpenMPTeamsDirective(OED->getDirectiveKind()) &&
+ OMPTeamsFound)) {
+

[PATCH] D56733: [OPENMP] update release note for implemented OMP 5.0 features

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 182556.
kkwli0 marked an inline comment as done.
kkwli0 added a comment.

Addressed reviewer's comment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56733/new/

https://reviews.llvm.org/D56733

Files:
  docs/OpenMPSupport.rst
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -133,7 +133,36 @@
 OpenMP Support in Clang
 --
 
-- ...
+- OpenMP 5.0 features
+
+  - Support relational-op != (not-equal) as one of the canonical forms of random
+access iterator.
+  - Added support for mapping of the lambdas in target regions.
+  - Added parsing/sema analysis for the requires directive.
+  - Support nested declare target directives.
+  - Make the `this` pointer implicitly mapped as `map(this[:1])`.
+  - Added the `close` *map-type-modifier*.
+
+- Various bugfixes and improvements.
+
+New features supported for Cuda devices:
+
+- Added support for the reductions across the teams.
+
+- Extended number of constructs that can be executed in SPMD mode.
+
+- Fixed support for lastprivate/reduction variables in SPMD constructs.
+
+- New collapse clause scheme to avoid expensive remainder operations.
+
+- New default schedule for distribute and parallel constructs.
+
+- Simplified code generation for distribute and parallel in SPMD mode.
+
+- Flag (``-fopenmp_optimistic_collapse``) for user to limit collapsed
+  loop counter width when safe to do so.
+
+- General performance improvement.
 
 CUDA Support in Clang
 -
Index: docs/OpenMPSupport.rst
===
--- docs/OpenMPSupport.rst
+++ docs/OpenMPSupport.rst
@@ -17,60 +17,50 @@
 OpenMP Support
 ==
 
-Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
-PPC64[LE] and has `basic support for Cuda devices`_.
-
-Standalone directives
-=
-
-* #pragma omp [for] simd: :good:`Complete`.
-
-* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
-  analysis + generation of special attributes for X86 target, but still
-  missing the LLVM pass for vectorization.
-
-* #pragma omp taskloop [simd]: :good:`Complete`.
-
-* #pragma omp target [enter|exit] data: :good:`Complete`.
-
-* #pragma omp target update: :good:`Complete`.
-
-* #pragma omp target: :good:`Complete`.
+Clang supports the following OpenMP 5.0 features
 
-* #pragma omp declare target: :good:`Complete`.
+* The `reduction`-based clauses in the `task` and `target`-based directives.
 
-* #pragma omp teams: :good:`Complete`.
+* Support relational-op != (not-equal) as one of the canonical forms of random
+  access iterator.
 
-* #pragma omp distribute [simd]: :good:`Complete`.
+* Support for mapping of the lambdas in target regions.
 
-* #pragma omp distribute parallel for [simd]: :good:`Complete`.
+* Parsing/sema analysis for the requires directive.
 
-Combined directives
-===
+* Nested declare target directives.
 
-* #pragma omp parallel for simd: :good:`Complete`.
+* Make the `this` pointer implicitly mapped as `map(this[:1])`.
 
-* #pragma omp target parallel: :good:`Complete`.
+* The `close` *map-type-modifier*.
 
-* #pragma omp target parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target simd: :good:`Complete`.
-
-* #pragma omp target teams: :good:`Complete`.
-
-* #pragma omp teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp teams distribute parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute parallel for [simd]: :good:`Complete`.
+Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
+PPC64[LE] and has `basic support for Cuda devices`_.
 
-Clang does not support any constructs/updates from OpenMP 5.0 except
-for `reduction`-based clauses in the `task` and `target`-based directives.
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
 
 In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools
-Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and mac OS.
+Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
+
+General improvements
+
+- New collapse clause scheme to avoid expensive remainder operations.
+  Compute loop index variables after collapsing a loop nest via the
+  collapse clause by replacing the expensive remainder operation with
+  multiplications and additions.
+
+- The default schedules for the `distribute` and `for` constructs in a
+  parallel region and in SPMD mode have changed to ensure coalesced
+  accesses. For the `distribute` construct, a static schedule is used
+ 

[PATCH] D56733: [OPENMP] update release note for implemented OMP 5.0 features

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: docs/OpenMPSupport.rst:62
+  
+- Simplified code generation for distribute and parallel in SPMD mode.
+

gtbercea wrote:
> Simplified SPMD code generation for `distribute parallel for` when the new 
> default schedules are applicable.
Will update the sentence.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56733/new/

https://reviews.llvm.org/D56733



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56733: [OPENMP] update release note for implemented OMP 5.0 features

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 182384.
kkwli0 added a reviewer: gtbercea.
kkwli0 added a comment.

Add changes in D56790 .


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56733/new/

https://reviews.llvm.org/D56733

Files:
  docs/OpenMPSupport.rst
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -133,7 +133,36 @@
 OpenMP Support in Clang
 --
 
-- ...
+- OpenMP 5.0 features
+
+  - Support relational-op != (not-equal) as one of the canonical forms of random
+access iterator.
+  - Added support for mapping of the lambdas in target regions.
+  - Added parsing/sema analysis for the requires directive.
+  - Support nested declare target directives.
+  - Make the `this` pointer implicitly mapped as `map(this[:1])`.
+  - Added the `close` *map-type-modifier*.
+
+- Various bugfixes and improvements.
+
+New features supported for Cuda devices:
+
+- Added support for the reductions across the teams.
+
+- Extended number of constructs that can be executed in SPMD mode.
+
+- Fixed support for lastprivate/reduction variables in SPMD constructs.
+
+- New collapse clause scheme to avoid expensive remainder operations.
+
+- New default schedule for distribute and parallel constructs.
+
+- Simplified code generation for distribute and parallel in SPMD mode.
+
+- Flag (``-fopenmp_optimistic_collapse``) for user to limit collapsed
+  loop counter width when safe to do so.
+
+- General performance improvement.
 
 CUDA Support in Clang
 -
Index: docs/OpenMPSupport.rst
===
--- docs/OpenMPSupport.rst
+++ docs/OpenMPSupport.rst
@@ -17,60 +17,50 @@
 OpenMP Support
 ==
 
-Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
-PPC64[LE] and has `basic support for Cuda devices`_.
-
-Standalone directives
-=
-
-* #pragma omp [for] simd: :good:`Complete`.
-
-* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
-  analysis + generation of special attributes for X86 target, but still
-  missing the LLVM pass for vectorization.
-
-* #pragma omp taskloop [simd]: :good:`Complete`.
-
-* #pragma omp target [enter|exit] data: :good:`Complete`.
-
-* #pragma omp target update: :good:`Complete`.
-
-* #pragma omp target: :good:`Complete`.
+Clang supports the following OpenMP 5.0 features
 
-* #pragma omp declare target: :good:`Complete`.
+* The `reduction`-based clauses in the `task` and `target`-based directives.
 
-* #pragma omp teams: :good:`Complete`.
+* Support relational-op != (not-equal) as one of the canonical forms of random
+  access iterator.
 
-* #pragma omp distribute [simd]: :good:`Complete`.
+* Support for mapping of the lambdas in target regions.
 
-* #pragma omp distribute parallel for [simd]: :good:`Complete`.
+* Parsing/sema analysis for the requires directive.
 
-Combined directives
-===
+* Nested declare target directives.
 
-* #pragma omp parallel for simd: :good:`Complete`.
+* Make the `this` pointer implicitly mapped as `map(this[:1])`.
 
-* #pragma omp target parallel: :good:`Complete`.
+* The `close` *map-type-modifier*.
 
-* #pragma omp target parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target simd: :good:`Complete`.
-
-* #pragma omp target teams: :good:`Complete`.
-
-* #pragma omp teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp teams distribute parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute parallel for [simd]: :good:`Complete`.
+Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
+PPC64[LE] and has `basic support for Cuda devices`_.
 
-Clang does not support any constructs/updates from OpenMP 5.0 except
-for `reduction`-based clauses in the `task` and `target`-based directives.
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
 
 In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools
-Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and mac OS.
+Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
+
+General improvements
+
+- New collapse clause scheme to avoid expensive remainder operations.
+  Compute loop index variables after collapsing a loop nest via the
+  collapse clause by replacing the expensive remainder operation with
+  multiplications and additions.
+
+- The default schedules for the `distribute` and `for` constructs in a
+  parallel region and in SPMD mode have changed to ensure coalesced
+  accesses. For the `distribute` construct, a stati

[PATCH] D56733: [OPENMP] update release note for implemented OMP 5.0 features

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

In D56733#1360221 , @gtbercea wrote:

> Could we add the changes in D56790  to this 
> diff?


Sure, I will do that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56733/new/

https://reviews.llvm.org/D56733



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56733: [OPENMP] update release note for implemented OMP 5.0 features

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 181834.
kkwli0 added a comment.

Add update in OpenMP support release note.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56733/new/

https://reviews.llvm.org/D56733

Files:
  docs/OpenMPSupport.rst
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -233,12 +233,15 @@
 OpenMP Support in Clang
 --
 
-- Support relational-op != (not-equal) as one of the canonical forms of random
-  access iterator.
-
-- Added support for mapping of the lambdas in target regions.
-
-- Added parsing/sema analysis for OpenMP 5.0 requires directive.
+- OpenMP 5.0 features
+
+  - Support relational-op != (not-equal) as one of the canonical forms of random
+access iterator.
+  - Added support for mapping of the lambdas in target regions.
+  - Added parsing/sema analysis for the requires directive.
+  - Support nested declare target directives.
+  - Make the `this` pointer implicitly mapped as `map(this[:1])`.
+  - Added the `close` *map-type-modifier*.
 
 - Various bugfixes and improvements.
 
Index: docs/OpenMPSupport.rst
===
--- docs/OpenMPSupport.rst
+++ docs/OpenMPSupport.rst
@@ -17,60 +17,32 @@
 OpenMP Support
 ==
 
-Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
-PPC64[LE] and has `basic support for Cuda devices`_.
-
-Standalone directives
-=
-
-* #pragma omp [for] simd: :good:`Complete`.
-
-* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
-  analysis + generation of special attributes for X86 target, but still
-  missing the LLVM pass for vectorization.
-
-* #pragma omp taskloop [simd]: :good:`Complete`.
-
-* #pragma omp target [enter|exit] data: :good:`Complete`.
-
-* #pragma omp target update: :good:`Complete`.
-
-* #pragma omp target: :good:`Complete`.
+Clang supports the following OpenMP 5.0 features
 
-* #pragma omp declare target: :good:`Complete`.
+* The `reduction`-based clauses in the `task` and `target`-based directives.
 
-* #pragma omp teams: :good:`Complete`.
+* Support relational-op != (not-equal) as one of the canonical forms of random
+  access iterator.
 
-* #pragma omp distribute [simd]: :good:`Complete`.
+* Support for mapping of the lambdas in target regions.
 
-* #pragma omp distribute parallel for [simd]: :good:`Complete`.
+* Parsing/sema analysis for the requires directive.
 
-Combined directives
-===
+* Nested declare target directives.
 
-* #pragma omp parallel for simd: :good:`Complete`.
+* Make the `this` pointer implicitly mapped as `map(this[:1])`.
 
-* #pragma omp target parallel: :good:`Complete`.
+* The `close` *map-type-modifier*.
 
-* #pragma omp target parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target simd: :good:`Complete`.
-
-* #pragma omp target teams: :good:`Complete`.
-
-* #pragma omp teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute [simd]: :good:`Complete`.
-
-* #pragma omp teams distribute parallel for [simd]: :good:`Complete`.
-
-* #pragma omp target teams distribute parallel for [simd]: :good:`Complete`.
+Clang fully supports OpenMP 4.5. Clang supports offloading to X86_64, AArch64,
+PPC64[LE] and has `basic support for Cuda devices`_.
 
-Clang does not support any constructs/updates from OpenMP 5.0 except
-for `reduction`-based clauses in the `task` and `target`-based directives.
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
 
 In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools
-Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and mac OS.
+Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
 
 .. _basic support for Cuda devices:
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D55928: [OpenMP] Add flag for preventing the extension to 64 bits for the collapse loop counter

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: docs/OpenMPSupport.rst:119
+time. To prevent this conservative choice and use at most 32 bits,
+compile your program with the `-fopenmp-max-32bit-collapse-width`.
+

ABataev wrote:
> -fopenmp-optimistic-collapse
How about -fopenmp-use-32bit-collapse-parameter?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55928/new/

https://reviews.llvm.org/D55928



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54441: [OPENMP] Support relational-op !- (not-equal) as one of the canonical forms of random access iterator

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Please do a rebase.  The test case teams_distribute_simd_loop_messages.cpp 
needs to update too.




Comment at: clang/lib/Sema/SemaOpenMP.cpp:3707
   ///   UB  >= Var
-  bool TestIsLessOp = false;
+  /// This will has no value when the condition is !=
+  llvm::Optional TestIsLessOp;

has -> have


Repository:
  rC Clang

https://reviews.llvm.org/D54441



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D51446: [OpenMP][bugfix] Add missing macros for Power

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

Need to update the test too?


Repository:
  rC Clang

https://reviews.llvm.org/D51446



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40996: Add --no-cuda-version-check in unknown-std.cpp

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 126258.
kkwli0 added a comment.

Using a mock CUDA installation works too.


https://reviews.llvm.org/D40996

Files:
  test/Driver/unknown-std.cpp


Index: test/Driver/unknown-std.cpp
===
--- test/Driver/unknown-std.cpp
+++ test/Driver/unknown-std.cpp
@@ -4,7 +4,7 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck 
--match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib %s -std=foobar -c 2>&1 | 
FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib 
--cuda-path=%S/Inputs/CUDA/usr/local/cuda %s -std=foobar -c 2>&1 | FileCheck 
--match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
 
 // CHECK: error: invalid value 'foobar' in '-std=foobar'
 // CHECK-NEXT: note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' 
standard


Index: test/Driver/unknown-std.cpp
===
--- test/Driver/unknown-std.cpp
+++ test/Driver/unknown-std.cpp
@@ -4,7 +4,7 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib %s -std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s -std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
 
 // CHECK: error: invalid value 'foobar' in '-std=foobar'
 // CHECK-NEXT: note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 126217.
kkwli0 marked an inline comment as done.

https://reviews.llvm.org/D40968

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_target_ast_print.cpp
  test/OpenMP/declare_target_messages.cpp

Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -19,6 +19,10 @@
 
 void c(); // expected-warning {{declaration is not declared in any declare target region}}
 
+void func() {} // expected-note {{'func' defined here}}
+
+#pragma omp declare target link(func) // expected-error {{function name is not allowed in 'link' clause}}
+
 extern int b;
 
 struct NonT {
Index: test/OpenMP/declare_target_ast_print.cpp
===
--- test/OpenMP/declare_target_ast_print.cpp
+++ test/OpenMP/declare_target_ast_print.cpp
@@ -108,9 +108,7 @@
 // CHECK: #pragma omp end declare target
 
 int c1, c2, c3;
-void f3() {
-}
-#pragma omp declare target link(c1) link(c2), link(c3, f3)
+#pragma omp declare target link(c1) link(c2), link(c3)
 // CHECK: #pragma omp declare target link
 // CHECK: int c1;
 // CHECK: #pragma omp end declare target
@@ -120,9 +118,6 @@
 // CHECK: #pragma omp declare target link
 // CHECK: int c3;
 // CHECK: #pragma omp end declare target
-// CHECK: #pragma omp declare target link
-// CHECK: void f3()
-// CHECK: #pragma omp end declare target
 
 struct SSSt {
 #pragma omp declare target
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -12600,7 +12600,7 @@
   ND->addAttr(A);
   if (ASTMutationListener *ML = Context.getASTMutationListener())
 ML->DeclarationMarkedOpenMPDeclareTarget(ND, A);
-  checkDeclIsAllowedInOpenMPTarget(nullptr, ND);
+  checkDeclIsAllowedInOpenMPTarget(nullptr, ND, Id.getLoc());
 } else if (ND->getAttr()->getMapType() != MT) {
   Diag(Id.getLoc(), diag::err_omp_declare_target_to_and_link)
   << Id.getName();
@@ -12689,7 +12689,8 @@
   return true;
 }
 
-void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D) {
+void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+SourceLocation IdLoc) {
   if (!D || D->isInvalidDecl())
 return;
   SourceRange SR = E ? E->getSourceRange() : D->getSourceRange();
@@ -12718,6 +12719,16 @@
   return;
 }
   }
+  if (FunctionDecl *FD = dyn_cast(D)) {
+if (FD->hasAttr() &&
+(FD->getAttr()->getMapType() ==
+ OMPDeclareTargetDeclAttr::MT_Link)) {
+  assert(IdLoc.isValid() && "Source location is expected");
+  Diag(IdLoc, diag::err_omp_function_in_link_clause);
+  Diag(FD->getLocation(), diag::note_defined_here) << FD;
+  return;
+}
+  }
   if (!E) {
 // Checking declaration inside declare target region.
 if (!D->hasAttr() &&
Index: include/clang/Sema/Sema.h
===
--- include/clang/Sema/Sema.h
+++ include/clang/Sema/Sema.h
@@ -8656,7 +8656,8 @@
 OMPDeclareTargetDeclAttr::MapTypeTy MT,
 NamedDeclSetType &SameDirectiveDecls);
   /// Check declaration inside target region.
-  void checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D);
+  void checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+SourceLocation IdLoc = SourceLocation());
   /// Return true inside OpenMP declare target region.
   bool isInOpenMPDeclareTargetContext() const {
 return IsInOpenMPDeclareTargetContext;
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -8709,6 +8709,8 @@
 def warn_omp_not_in_target_context : Warning<
   "declaration is not declared in any declare target region">,
   InGroup;
+def err_omp_function_in_link_clause : Error<
+  "function name is not allowed in 'link' clause">;
 def err_omp_aligned_expected_array_or_ptr : Error<
   "argument of aligned clause should be array"
   "%select{ or pointer|, pointer, reference to array or reference to pointer}1"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:12671
+void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+const DeclarationNameInfo *Id) {
   if (!D || D->isInvalidDecl())

ABataev wrote:
> kkwli0 wrote:
> > ABataev wrote:
> > > You can get `DeclarationNameInfo` from the `FunctionDecl`:
> > > ```
> > > FD->getNameInfo()
> > > ```
> > This FD->getNameInfo() will only give the name info from the function 
> > definition.  What we need here is the name info for 'foo' that appears on 
> > the pragma in order to give us
> > 
> > ```
> > d2.c:2:33: error: function name is not allowed in 'link' clause
> > #pragma omp declare target link(foo)
> > ^
> > ```
> Then just pass `SourceLocation`
Sure.


https://reviews.llvm.org/D40968



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:12671
+void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+const DeclarationNameInfo *Id) {
   if (!D || D->isInvalidDecl())

ABataev wrote:
> You can get `DeclarationNameInfo` from the `FunctionDecl`:
> ```
> FD->getNameInfo()
> ```
This FD->getNameInfo() will only give the name info from the function 
definition.  What we need here is the name info for 'foo' that appears on the 
pragma in order to give us

```
d2.c:2:33: error: function name is not allowed in 'link' clause
#pragma omp declare target link(foo)
^
```


https://reviews.llvm.org/D40968



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40996: Add --no-cuda-version-check in unknown-std.cpp

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.

This unit test fails on the system that has CUDA Toolkit 9.0 installed.  And 
CUDA 9 does not support GPU arch sm_20.  It results in the following error.

  clang-6.0: error: GPU arch sm_20 is supported by CUDA versions between 7.0 
and 8.0 (inclusive), but installation at /usr/local/cuda is 9.0.  Use 
--cuda-path to specify a different CUDA install, pass a different GPU arch with 
--cuda-gpu-arch, or pass --no-cuda-version-check.


https://reviews.llvm.org/D40996

Files:
  test/Driver/unknown-std.cpp


Index: test/Driver/unknown-std.cpp
===
--- test/Driver/unknown-std.cpp
+++ test/Driver/unknown-std.cpp
@@ -4,7 +4,7 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck 
--match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib %s -std=foobar -c 2>&1 | 
FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib --no-cuda-version-check %s 
-std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK 
--check-prefix=CUDA %s
 
 // CHECK: error: invalid value 'foobar' in '-std=foobar'
 // CHECK-NEXT: note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' 
standard


Index: test/Driver/unknown-std.cpp
===
--- test/Driver/unknown-std.cpp
+++ test/Driver/unknown-std.cpp
@@ -4,7 +4,7 @@
 
 // RUN: not %clang %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
 // RUN: not %clang -x objective-c++ %s -std=foobar -c 2>&1 | FileCheck --match-full-lines %s
-// RUN: not %clang -x cuda -nocudainc -nocudalib %s -std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
+// RUN: not %clang -x cuda -nocudainc -nocudalib --no-cuda-version-check %s -std=foobar -c 2>&1 | FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA %s
 
 // CHECK: error: invalid value 'foobar' in '-std=foobar'
 // CHECK-NEXT: note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 126025.
kkwli0 marked an inline comment as done.

https://reviews.llvm.org/D40968

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_target_ast_print.cpp
  test/OpenMP/declare_target_messages.cpp

Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -19,6 +19,10 @@
 
 void c(); // expected-warning {{declaration is not declared in any declare target region}}
 
+void func() {} // expected-note {{'func' defined here}}
+
+#pragma omp declare target link(func) // expected-error {{function name is not allowed in 'link' clause}}
+
 extern int b;
 
 struct NonT {
Index: test/OpenMP/declare_target_ast_print.cpp
===
--- test/OpenMP/declare_target_ast_print.cpp
+++ test/OpenMP/declare_target_ast_print.cpp
@@ -108,9 +108,7 @@
 // CHECK: #pragma omp end declare target
 
 int c1, c2, c3;
-void f3() {
-}
-#pragma omp declare target link(c1) link(c2), link(c3, f3)
+#pragma omp declare target link(c1) link(c2), link(c3)
 // CHECK: #pragma omp declare target link
 // CHECK: int c1;
 // CHECK: #pragma omp end declare target
@@ -120,9 +118,6 @@
 // CHECK: #pragma omp declare target link
 // CHECK: int c3;
 // CHECK: #pragma omp end declare target
-// CHECK: #pragma omp declare target link
-// CHECK: void f3()
-// CHECK: #pragma omp end declare target
 
 struct SSSt {
 #pragma omp declare target
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -12578,7 +12578,7 @@
   ND->addAttr(A);
   if (ASTMutationListener *ML = Context.getASTMutationListener())
 ML->DeclarationMarkedOpenMPDeclareTarget(ND, A);
-  checkDeclIsAllowedInOpenMPTarget(nullptr, ND);
+  checkDeclIsAllowedInOpenMPTarget(nullptr, ND, &Id);
 } else if (ND->getAttr()->getMapType() != MT) {
   Diag(Id.getLoc(), diag::err_omp_declare_target_to_and_link)
   << Id.getName();
@@ -12667,7 +12667,8 @@
   return true;
 }
 
-void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D) {
+void Sema::checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+const DeclarationNameInfo *Id) {
   if (!D || D->isInvalidDecl())
 return;
   SourceRange SR = E ? E->getSourceRange() : D->getSourceRange();
@@ -12696,6 +12697,16 @@
   return;
 }
   }
+  if (FunctionDecl *FD = dyn_cast(D)) {
+if (FD->hasAttr() &&
+(FD->getAttr()->getMapType() ==
+ OMPDeclareTargetDeclAttr::MT_Link)) {
+  assert(Id && "Null decl name info on link clause.");
+  Diag(Id->getLoc(), diag::err_omp_function_in_link_clause);
+  Diag(FD->getLocation(), diag::note_defined_here) << FD;
+  return;
+}
+  }
   if (!E) {
 // Checking declaration inside declare target region.
 if (!D->hasAttr() &&
Index: include/clang/Sema/Sema.h
===
--- include/clang/Sema/Sema.h
+++ include/clang/Sema/Sema.h
@@ -8652,7 +8652,8 @@
 OMPDeclareTargetDeclAttr::MapTypeTy MT,
 NamedDeclSetType &SameDirectiveDecls);
   /// Check declaration inside target region.
-  void checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D);
+  void checkDeclIsAllowedInOpenMPTarget(Expr *E, Decl *D,
+const DeclarationNameInfo *Id = nullptr);
   /// Return true inside OpenMP declare target region.
   bool isInOpenMPDeclareTargetContext() const {
 return IsInOpenMPDeclareTargetContext;
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -8709,6 +8709,8 @@
 def warn_omp_not_in_target_context : Warning<
   "declaration is not declared in any declare target region">,
   InGroup;
+def err_omp_function_in_link_clause : Error<
+  "function name is not allowed in 'link' clause">;
 def err_omp_aligned_expected_array_or_ptr : Error<
   "argument of aligned clause should be array"
   "%select{ or pointer|, pointer, reference to array or reference to pointer}1"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:12576
 
+if (MT == OMPDeclareTargetDeclAttr::MT_Link && isa(ND)) {
+  Diag(Id.getLoc(), diag::err_omp_function_in_link_clause);

ABataev wrote:
> I would like to see this some in `check` functions, like 
> `checkDeclIsAllowedInOpenMPTarget` rather than here 
Sure.  I will move the check into checkDeclIsAllowedInOpenMPTarget.


https://reviews.llvm.org/D40968



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40968: [OpenMP] Diagnose function name on the link clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.

This patch is to add diagnose when a function name is specified on the link 
clause.  According to the OpenMP spec, only the list items that exclude the 
function name are allowed on the link clause.

  void foo() {}
  #pragma omp declare target link(foo)



  d2.c:2:33: error: function name is not allowed in 'link' clause
  #pragma omp declare target link(foo)
  ^
  d2.c:1:6: note: 'foo' defined here
  void foo() {}
   ^
  1 error generated.


https://reviews.llvm.org/D40968

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_target_ast_print.cpp
  test/OpenMP/declare_target_messages.cpp


Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -19,6 +19,10 @@
 
 void c(); // expected-warning {{declaration is not declared in any declare 
target region}}
 
+void func() {} // expected-note {{'func' defined here}}
+
+#pragma omp declare target link(func) // expected-error {{function name is not 
allowed in 'link' clause}}
+
 extern int b;
 
 struct NonT {
Index: test/OpenMP/declare_target_ast_print.cpp
===
--- test/OpenMP/declare_target_ast_print.cpp
+++ test/OpenMP/declare_target_ast_print.cpp
@@ -108,9 +108,7 @@
 // CHECK: #pragma omp end declare target
 
 int c1, c2, c3;
-void f3() {
-}
-#pragma omp declare target link(c1) link(c2), link(c3, f3)
+#pragma omp declare target link(c1) link(c2), link(c3)
 // CHECK: #pragma omp declare target link
 // CHECK: int c1;
 // CHECK: #pragma omp end declare target
@@ -120,9 +118,6 @@
 // CHECK: #pragma omp declare target link
 // CHECK: int c3;
 // CHECK: #pragma omp end declare target
-// CHECK: #pragma omp declare target link
-// CHECK: void f3()
-// CHECK: #pragma omp end declare target
 
 struct SSSt {
 #pragma omp declare target
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -12573,6 +12573,11 @@
 if (!SameDirectiveDecls.insert(cast(ND->getCanonicalDecl(
   Diag(Id.getLoc(), diag::err_omp_declare_target_multiple) << Id.getName();
 
+if (MT == OMPDeclareTargetDeclAttr::MT_Link && isa(ND)) {
+  Diag(Id.getLoc(), diag::err_omp_function_in_link_clause);
+  Diag(ND->getLocation(), diag::note_defined_here) << ND;
+}
+
 if (!ND->hasAttr()) {
   Attr *A = OMPDeclareTargetDeclAttr::CreateImplicit(Context, MT);
   ND->addAttr(A);
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -8709,6 +8709,8 @@
 def warn_omp_not_in_target_context : Warning<
   "declaration is not declared in any declare target region">,
   InGroup;
+def err_omp_function_in_link_clause : Error<
+  "function name is not allowed in 'link' clause">;
 def err_omp_aligned_expected_array_or_ptr : Error<
   "argument of aligned clause should be array"
   "%select{ or pointer|, pointer, reference to array or reference to pointer}1"


Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -19,6 +19,10 @@
 
 void c(); // expected-warning {{declaration is not declared in any declare target region}}
 
+void func() {} // expected-note {{'func' defined here}}
+
+#pragma omp declare target link(func) // expected-error {{function name is not allowed in 'link' clause}}
+
 extern int b;
 
 struct NonT {
Index: test/OpenMP/declare_target_ast_print.cpp
===
--- test/OpenMP/declare_target_ast_print.cpp
+++ test/OpenMP/declare_target_ast_print.cpp
@@ -108,9 +108,7 @@
 // CHECK: #pragma omp end declare target
 
 int c1, c2, c3;
-void f3() {
-}
-#pragma omp declare target link(c1) link(c2), link(c3, f3)
+#pragma omp declare target link(c1) link(c2), link(c3)
 // CHECK: #pragma omp declare target link
 // CHECK: int c1;
 // CHECK: #pragma omp end declare target
@@ -120,9 +118,6 @@
 // CHECK: #pragma omp declare target link
 // CHECK: int c3;
 // CHECK: #pragma omp end declare target
-// CHECK: #pragma omp declare target link
-// CHECK: void f3()
-// CHECK: #pragma omp end declare target
 
 struct SSSt {
 #pragma omp declare target
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -12573,6 +12573,11 @@
 if (!SameDirectiveDecls.insert(cast(ND->getCanonicalDecl(
   Diag(Id.getLoc(), diag::err_omp_declare_target_multiple) << Id.getName();
 
+if (MT == OMPDeclareTarge

[PATCH] D40588: [OpenMP] Diagnose undeclared variables on declare target clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 updated this revision to Diff 124811.
kkwli0 added a comment.

The assert occurs in VarOrFuncDeclFilterCCC::ValidateCandidate when 
clang::Sema::CorrectTypo is called.


https://reviews.llvm.org/D40588

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_target_messages.cpp


Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -13,6 +13,10 @@
 
 #pragma omp declare target map(a) // expected-error {{unexpected 'map' clause, 
only 'to' or 'link' clauses expected}}
 
+#pragma omp declare target to(foo1) // expected-error {{use of undeclared 
identifier 'foo1'}}
+
+#pragma omp declare target link(foo2) // expected-error {{use of undeclared 
identifier 'foo2'}}
+
 void c(); // expected-warning {{declaration is not declared in any declare 
target region}}
 
 extern int b;
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -1506,7 +1506,7 @@
   explicit VarOrFuncDeclFilterCCC(Sema &S) : SemaRef(S) {}
   bool ValidateCandidate(const TypoCorrection &Candidate) override {
 NamedDecl *ND = Candidate.getCorrectionDecl();
-if (isa(ND) || isa(ND)) {
+if (ND && (isa(ND) || isa(ND))) {
   return SemaRef.isDeclInScope(ND, SemaRef.getCurLexicalContext(),
SemaRef.getCurScope());
 }


Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -13,6 +13,10 @@
 
 #pragma omp declare target map(a) // expected-error {{unexpected 'map' clause, only 'to' or 'link' clauses expected}}
 
+#pragma omp declare target to(foo1) // expected-error {{use of undeclared identifier 'foo1'}}
+
+#pragma omp declare target link(foo2) // expected-error {{use of undeclared identifier 'foo2'}}
+
 void c(); // expected-warning {{declaration is not declared in any declare target region}}
 
 extern int b;
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -1506,7 +1506,7 @@
   explicit VarOrFuncDeclFilterCCC(Sema &S) : SemaRef(S) {}
   bool ValidateCandidate(const TypoCorrection &Candidate) override {
 NamedDecl *ND = Candidate.getCorrectionDecl();
-if (isa(ND) || isa(ND)) {
+if (ND && (isa(ND) || isa(ND))) {
   return SemaRef.isDeclInScope(ND, SemaRef.getCurLexicalContext(),
SemaRef.getCurScope());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40588: [OpenMP] Diagnose undeclared variables on declare target clause

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

The original case has the variables named "foo1" and foo2".  Using "foo1" or 
"foo2" causes the assert!  I update the description.


https://reviews.llvm.org/D40588



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31417: [OpenMP] Add support for omp simd pragmas without runtime

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added inline comments.



Comment at: docs/ClangCommandLineReference.rst:1454
 
+.. option:: -fopenmp-simd, -fno-openmp-simd
+

I am not sure if it is target architecture specific or not.  If it is, should 
we be under the target flag instead?


https://reviews.llvm.org/D31417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28252: [OpenMP] Sema and parsing for 'target teams distribute simd' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:6444
+
+  CapturedStmt *CS = cast(AStmt);
+  // 1.2.2 OpenMP Language Terminology

ABataev wrote:
> auto *
Will do.


https://reviews.llvm.org/D28252



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28402: [OpenMP] support the 'is_device_ptr' clause with 'target parallel for simd' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: ABataev, sfantao, carlo.bertolli, arpith-jacob, 
mikerice, hfinkel.
kkwli0 added a subscriber: cfe-commits.

This patch is to add support of the 'is_device_ptr' clause in the 'target 
parallel for simd' pragma.


https://reviews.llvm.org/D28402

Files:
  include/clang/Basic/OpenMPKinds.def
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/target_parallel_for_simd_is_device_ptr_ast_print.cpp
  test/OpenMP/target_parallel_for_simd_is_device_ptr_messages.cpp

Index: test/OpenMP/target_parallel_for_simd_is_device_ptr_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_parallel_for_simd_is_device_ptr_messages.cpp
@@ -0,0 +1,337 @@
+// RUN: %clang_cc1 -std=c++11 -verify -fopenmp %s
+struct ST {
+  int *a;
+};
+typedef int arr[10];
+typedef ST STarr[10];
+struct SA {
+  const int d = 5;
+  const int da[5] = { 0 };
+  ST e;
+  ST g[10];
+  STarr &rg = g;
+  int i;
+  int &j = i;
+  int *k = &j;
+  int *&z = k;
+  int aa[10];
+  arr &raa = aa;
+  void func(int arg) {
+#pragma omp target parallel for simd is_device_ptr // expected-error {{expected '(' after 'is_device_ptr'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr() // expected-error {{expected expression}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(arg // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(i) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(j) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(k) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(z) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(aa) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(raa) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(e) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(g) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(rg) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(k,i,j) // expected-error2 {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(d) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(da) // OK
+  for (int i=0; i<100; i++)
+;
+  return;
+ }
+};
+struct SB {
+  unsigned A;
+  unsigned B;
+  float Arr[100];
+  float *Ptr;
+  float *foo() {
+return &Arr[0];
+  }
+};
+
+struct SC {
+  unsigned A : 2;
+  unsigned B : 3;
+  unsigned C;
+  unsigned D;
+  float Arr[100];
+  SB S;
+  SB ArrS[100];
+  SB *PtrS;
+  SB *&RPtrS;
+  float *Ptr;
+
+  SC(SB *&_RPtrS) : RPtrS(_RPtrS) {}
+};
+
+union SD {
+  unsigned A;
+  float B;
+};
+
+struct S1;
+extern S1 a;
+class S2 {
+  mutable int a;
+public:
+  S2():a(0) { }
+  S2(S2 &s2):a(s2.a) { }
+  static float S2s;
+  static const float S2sc;
+};
+const float S2::S2sc = 0;
+const S2 b;
+const S2 ba[5];
+class S3 {
+  int a;
+public:
+  S3():a(0) { }
+  S3(S3 &s3):a(s3.a) { }
+};
+const S3 c;
+const S3 ca[5];
+extern const int f;
+class S4 {
+  int a;
+  S4();
+  S4(const S4 &s4);
+public:
+  S4(int v):a(v) { }
+};
+class S5 {
+  int a;
+  S5():a(0) {}
+  S5(const S5 &s5):a(s5.a) { }
+public:
+  S5(int v):a(v) { }
+};
+
+S3 h;
+#pragma omp threadprivate(h)
+
+typedef struct {
+  int a;
+} S6;
+
+template 
+T tmain(T argc) {
+  const T d = 5;
+  const T da[5] = { 0 };
+  S4 e(4);
+  S5 g(5);
+  S6 h[10];
+  auto &rh = h;
+  T i;
+  T &j = i;
+  T *k = &j;
+  T *&z = k;
+  T aa[10];
+  auto &raa = aa;
+  S6 *ps;
+#pragma omp target parallel for simd i

[PATCH] D28255: [OpenMP] support the 'is_device_ptr' clause with 'target parallel for' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: ABataev, sfantao, carlo.bertolli, arpith-jacob, 
hfinkel, mikerice.
kkwli0 added a subscriber: cfe-commits.

This patch is to add support of the 'is_device_ptr' clause in the 'target 
parallel for' pragma.


https://reviews.llvm.org/D28255

Files:
  include/clang/Basic/OpenMPKinds.def
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/target_parallel_for_is_device_ptr_ast_print.cpp
  test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp

Index: test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp
@@ -0,0 +1,311 @@
+// RUN: %clang_cc1 -std=c++11 -verify -fopenmp %s
+
+struct ST {
+  int *a;
+};
+typedef int arr[10];
+typedef ST STarr[10];
+typedef struct {
+  int a;
+} S;
+struct SA {
+  const int d = 5;
+  const int da[5] = { 0 };
+  ST e;
+  ST g[10];
+  STarr &rg = g;
+  int i;
+  int &j = i;
+  int *k = &j;
+  int *&z = k;
+  int aa[10];
+  arr &raa = aa;
+  S *ps;
+  void func(int arg) {
+#pragma omp target parallel for is_device_ptr // expected-error {{expected '(' after 'is_device_ptr'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr() // expected-error {{expected expression}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(arg // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(i) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(j) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(k) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(z) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(aa) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(raa) // OK
+for (int ii=0; ii<10; ii++)
+  ;   
+#pragma omp target parallel for is_device_ptr(e) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(g) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(rg) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(k,i,j) // expected-error2 {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(d) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(da) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for map(ps) is_device_ptr(ps) // expected-error{{variable already marked as mapped in current construct}} expected-note{{used here}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(ps) map(ps) // expected-error{{variable already marked as mapped in current construct}} expected-note{{used here}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for map(ps->a) is_device_ptr(ps) // expected-error{{variable already marked as mapped in current construct}} expected-note{{used here}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(ps) map(ps->a) // expected-error{{pointer cannot be mapped along with a section derived from itself}} expected-note{{used here}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for firstprivate(ps) is_device_ptr(ps) // expected-error{{firstprivate variable cannot be in a is_device_ptr clause in '#pragma omp target parallel for' directive}} expected-note{{defined as firstprivate}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for private(ps) is_device_ptr(ps) // expected-error{{private variable cannot be in a is_device_ptr cla

[PATCH] D27821: [OpenMP] support is_device_ptr clause with 'target parallel' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 created this revision.
kkwli0 added reviewers: ABataev, hfinkel, carlo.bertolli, sfantao, 
arpith-jacob, mikerice.
kkwli0 added a subscriber: cfe-commits.

This patch is to add support of the 'is_device_ptr' clause in the 'target 
parallel' pragma.


https://reviews.llvm.org/D27821

Files:
  include/clang/Basic/OpenMPKinds.def
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/target_parallel_is_device_ptr_ast_print.cpp
  test/OpenMP/target_parallel_is_device_ptr_messages.cpp

Index: test/OpenMP/target_parallel_is_device_ptr_messages.cpp
===
--- /dev/null
+++ test/OpenMP/target_parallel_is_device_ptr_messages.cpp
@@ -0,0 +1,268 @@
+// RUN: %clang_cc1 -std=c++11 -verify -fopenmp -ferror-limit 200 %s
+struct ST {
+  int *a;
+};
+typedef int arr[10];
+typedef ST STarr[10];
+struct SA {
+  const int d = 5;
+  const int da[5] = { 0 };
+  ST e;
+  ST g[10];
+  STarr &rg = g;
+  int i;
+  int &j = i;
+  int *k = &j;
+  int *&z = k;
+  int aa[10];
+  arr &raa = aa;
+  void func(int arg) {
+#pragma omp target parallel is_device_ptr // expected-error {{expected '(' after 'is_device_ptr'}}
+{}
+#pragma omp target parallel is_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+{}
+#pragma omp target parallel is_device_ptr() // expected-error {{expected expression}}
+{}
+#pragma omp target parallel is_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+{}
+#pragma omp target parallel is_device_ptr(arg // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(i) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(j) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(k) // OK
+{}
+#pragma omp target parallel is_device_ptr(z) // OK
+{}
+#pragma omp target parallel is_device_ptr(aa) // OK
+{}
+#pragma omp target parallel is_device_ptr(raa) // OK
+{}
+#pragma omp target parallel is_device_ptr(e) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(g) // OK
+{}
+#pragma omp target parallel is_device_ptr(rg) // OK
+{}
+#pragma omp target parallel is_device_ptr(k,i,j) // expected-error2 {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(d) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+{}
+#pragma omp target parallel is_device_ptr(da) // OK
+{}
+  return;
+ }
+};
+struct SB {
+  unsigned A;
+  unsigned B;
+  float Arr[100];
+  float *Ptr;
+  float *foo() {
+return &Arr[0];
+  }
+};
+
+struct SC {
+  unsigned A : 2;
+  unsigned B : 3;
+  unsigned C;
+  unsigned D;
+  float Arr[100];
+  SB S;
+  SB ArrS[100];
+  SB *PtrS;
+  SB *&RPtrS;
+  float *Ptr;
+
+  SC(SB *&_RPtrS) : RPtrS(_RPtrS) {}
+};
+
+union SD {
+  unsigned A;
+  float B;
+};
+
+struct S1;
+extern S1 a;
+class S2 {
+  mutable int a;
+public:
+  S2():a(0) { }
+  S2(S2 &s2):a(s2.a) { }
+  static float S2s;
+  static const float S2sc;
+};
+const float S2::S2sc = 0;
+const S2 b;
+const S2 ba[5];
+class S3 {
+  int a;
+public:
+  S3():a(0) { }
+  S3(S3 &s3):a(s3.a) { }
+};
+const S3 c;
+const S3 ca[5];
+extern const int f;
+class S4 {
+  int a;
+  S4();
+  S4(const S4 &s4);
+public:
+  S4(int v):a(v) { }
+};
+class S5 {
+  int a;
+  S5():a(0) {}
+  S5(const S5 &s5):a(s5.a) { }
+public:
+  S5(int v):a(v) { }
+};
+
+S3 h;
+#pragma omp threadprivate(h)
+
+typedef struct {
+  int a;
+} S6;
+
+template 
+T tmain(T argc) {
+  const T d = 5;
+  const T da[5] = { 0 };
+  S4 e(4);
+  S5 g(5);
+  S6 h[10];
+  auto &rh = h;
+  T i;
+  T &j = i;
+  T *k = &j;
+  T *&z = k;
+  T aa[10];
+  auto &raa = aa;
+  S6 *ps;
+#pragma omp target parallel is_device_ptr // expected-error {{expected '(' after 'is_device_ptr'}}
+  {}
+#pragma omp target parallel is_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+  {}
+#pragma omp target parallel is_device_ptr() // expected-error {{expected expression}}
+  {}
+#pragma omp target parallel is_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+  {}
+#pragma omp target parallel is_device_ptr(argc // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device

[PATCH] D27345: [OpenMP] Sema and parsing for 'teams distribute parallel for' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Basic/OpenMPKinds.cpp:757
  Kind == OMPD_distribute_parallel_for_simd ||
  Kind == OMPD_distribute_simd;
   // TODO add next directives.

ABataev wrote:
> Should it be added here along with OMPD_teams_distribute_parallel_for_simd? 
The isOpenMPNestingDistributeDirective is for the construct that has distribute 
be the outermost (e.g. distribute *) so that it can be checked against the 
nesting region whether it is teams or not.  I do not think it is necessary to 
add it here.


https://reviews.llvm.org/D27345



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27488: Fixing test to work when the compiler defaults to a different c++ standard version.

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 added a comment.

I am okay with the changes.  Thanks.  Alexey will have the final say.


https://reviews.llvm.org/D27488



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27084: [OpenMP] Sema and parsing for 'teams distribute parallel for simd' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked 2 inline comments as done.
kkwli0 added inline comments.



Comment at: test/OpenMP/nesting_of_regions.cpp:3326
   }
-#pragma omp ordered
   {

ABataev wrote:
> what about teams distribute parallel for simd inside the ordered directive? 
> Why this one is removed?
This is a typo (likely due to copy and paste error), it should be atomic as 
this section is to test constructs nested inside an atomic construct.  The 
testing of constructs nested inside an ordered construct is in line 2910-3149.


https://reviews.llvm.org/D27084



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits