rjmccall added a comment. In https://reviews.llvm.org/D53705#1281738, @keryell wrote:
> In https://reviews.llvm.org/D53705#1278066, @rjmccall wrote: > > > I don't suppose there's any chance you can just tell Khronos to fix their > > stuff. It's a little funny to be more conservative about keywords in C++ > > when the C++ committee is actually much more aggressive about adding > > keywords in the non-reserved space than C is. > > > You are actually telling this to Khronos since a lot of Khronos members are > on the LLVM mailing lists and are reading this right now... :-) Great. > I am unsure to understand what you mean about "the C++ committee is actually > much more aggressive about adding keywords in the non-reserved space than C > is". New versions of C++ have semi-regularly added keywords like `static_assert` and `thread_local` that are not in the reserved space for identifiers. When C adopted these, it spelled them `_Static_assert` and `_Thread_local`, which are in the reserved space. I was under the mistaken (right?) impression thought that e.g. `__constant` was a standardized spelling, and I thought that Khronos had just decided to avoid using the unreserved identifiers in C++ when it had gladly adopted them in C. But now I understand that OpenCL C++ is attempting to be a radically different language model that does not actually have qualifiers at all. > The motivation behind this was to have 0 language extension to C++ in OpenCL > C++, like with the single-source version of the standard, SYCL, where you can > have a program which is executed purely on CPU without any compiler support, > to avoid the CUDA & C++AMP atrocities. By "0 language extension", do you just mean no *syntactic* extensions? Because something like `cl::priv` certainly seems like it requires intrinsic language support, and I don't know what `add_global_t` could possibly do besides add a not-described-in-the-standard-but-still-obviously-there address-space qualifier so that member accesses continue to work and properly preserve the qualifier on the resulting l-value. C++ doesn't provide adequate language tools to replace pointers and references at a language level, not by a long shot; the tools are only really good enough for resource management. The "just compile C++ code for the GPU" idea that (IIRC) AMD has been exploring seems quite interesting, but unlike OpenCL C++ it really is a largely no-extensions approach: it's implementing the classic C++ language model (with facilities for taking more control) like any other frontend, just with a weird target on the backend. It's also just hoping that the optimizer will be able to eliminate the overheads when mapping to a multiple-address-space model, and I'm not sure whether that's been borne out. OpenCL C++ seems to be trying to strike a middle ground where there are minimal syntactic extensions but the type system is rather radically different in ways that often work but also often don't, and it's basically held together by the underlying extensions that it's pretending aren't there. That doesn't seem like a successful language approach. Also, I have no opinion about CUDA or C++AMP but feel I need to distance myself from your comment about them. > That seems like a good discussion topic next Thursday at the LLVM Bay Area > Meetup. :-) Alas, I live in New York; I was just out there for the Developer's Meeting but won't be back for some time. Repository: rC Clang https://reviews.llvm.org/D53705 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
