[PATCH] D100976: [OpenCL] Simplify use of C11 atomic types

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added inline comments.


================
Comment at: clang/test/Parser/opencl-atomics-cl20.cl:7-8
 
-#ifdef EXT
-#pragma OPENCL EXTENSION cl_khr_int64_base_atomics:enable
-#pragma OPENCL EXTENSION cl_khr_int64_extended_atomics:enable
-#pragma OPENCL EXTENSION cl_khr_fp64:enable
-#if __OPENCL_C_VERSION__ >= CL_VERSION_1_2
-// expected-warning at -2{{OpenCL extension 'cl_khr_fp64' is core feature or supported optional core feature - ignoring}}
-#endif
+#if defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= CL_VERSION_1_2
+#define LANG_VER_OK
 #endif
----------------
Mauby simply //-DLANG_VER_OK// when running tests?


================
Comment at: clang/test/Parser/opencl-atomics-cl20.cl:51-56
+// expected-error at -21 {{expected ';' after expression}}
+// expected-error at -22 {{use of undeclared identifier 's'}}
+// expected-error at -22 {{unknown type name 'atomic_intptr_t'; did you mean 'atomic_int'?}}
+// expected-note@* {{'atomic_int' declared here}}
+// expected-error at -23 {{unknown type name 'atomic_uintptr_t'; did you mean 'atomic_uint'?}}
+// expected-note@* {{'atomic_uint' declared here}}
----------------
Well, this is exactly what I was afraid of last time, see https://reviews.llvm.org/D97058#2602677. Is this for sure a right way to go forward? Also, **declared //here//** for implicit type definitions is pretty confusing. Maybe a way the diagnostics showed here is just a bug?


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

https://reviews.llvm.org/D100976