rjmccall added a comment. In https://reviews.llvm.org/D53705#1280264, @Anastasia wrote:
> In https://reviews.llvm.org/D53705#1279086, @rjmccall wrote: > > > In https://reviews.llvm.org/D53705#1279068, @svenvh wrote: > > > > > Unlikely, since address spaces are provided in a different way in OpenCL > > > C++ vs OpenCL C. > > > > > > OpenCL C provides qualifiers such as `global` as part of the language. > > > OpenCL C++ provides template classes such as `cl::global<T>` through a > > > header file. > > > > > > So OpenCL C code has to be completely rewritten if it needs to be used as > > part of an OpenCL C++ program? And it doesn't really compose like a type > > if it's supposed to change how a variable is stored. What a terrible > > little mess they've made for themselves. > > > Fair point. I would like to allow regular OpenCL address space qualifiers as > a Clang feature at least, in case we won't be able to alter the spec. But one > problem is that the `private` address space qualifier keyword conflicts with > the `private` class access modifier. I guess we can only allow the address > space qualifiers with the `__` prefix. So some existing code would have to be > changed when ported to OpenCL C++, but it should be easier than rewriting > using classes. That's actually a really easy ambiguity to handle given the current uses of the access-modifier keywords. You just don't parse `private` as an access modifier if it's not followed by a colon. 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
