Anastasia added inline comments.
================ Comment at: include/clang/Basic/OpenCLExtensionTypes.def:27 + +INTEL_SGAVC_TYPE(mce_payload_t, McePayload) +INTEL_SGAVC_TYPE(ime_payload_t, ImePayload) ---------------- AlexeySachkov wrote: > Anastasia wrote: > > From the specification of this extension I can't quite see if these types > > have to be in Clang instead of the header. Can you please elaborate on any > > example where it wouldn't be possible for this type to be declared in the > > header using the technique explained in: > > https://clang.llvm.org/docs/UsersManual.html#opencl-extensions > We cannot define these types in header because their layout is not defined in > specification, i.e. all of these types are opaque This is not the reason to add functionality to Clang. You can easily sort such things with target specific headers or even general headers (see `ndrange_t` for example). Spec doesn't have to describe everything. The question is whether there is something about those types that can't be handled using standard include mechanisms. Usually it's prohibited behaviors that can't be represented with such mechanisms. Like if some operations have to be disallowed or allowed (since in OpenCL C you can't define user defined operators) with the types. I think the trend is to avoid adding complexity into Clang, unless there is no other way to implement some feature correctly. Repository: rC Clang https://reviews.llvm.org/D51484 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
