rjmccall added a comment. In https://reviews.llvm.org/D53705#1284734, @keryell wrote:
> In https://reviews.llvm.org/D53705#1284268, @rjmccall wrote: > > > > > > > > > Okay. So the purpose of OpenCL C++ is to provide a non-unified model that > > allows you to easily run C++ code on the CPU. > > It is just the second-order purpose. > A C++-based kernel language to program accelerators without C++ language > extension, so that the code could also mostly run on a CPU without a specific > compiler. So, as a C++ language expert, I don't think this is actually possible without major compromises (e.g. preventing users from using `struct`s in non-generic address spaces), and I think you're being somewhat willfully blind about the extent to which you are going to be relying on language extensions — in ways that are unavoidably exposed in the language, and which therefore can change the well-formedness or dynamic behavior of the program — to make this work on a GPU (or any other device with interesting address spaces). If your plan is to compile code for the CPU with a normal C++ compiler but for the GPU with an OpenCL-aware compiler, you are going to have significantly divergent behavior between the CPU and GPU language dialects because of the non-standardness of the GPU dialect. 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
