jlebar added inline comments. ================ Comment at: lib/Headers/__clang_cuda_runtime_wrapper.h:72 @@ -71,1 +71,3 @@ +#if defined(CUDA_VECTOR_TYPES) +// Prevent inclusion of CUDA's vector_types.h ---------------- The compiler driver is responsible for enabling/disabling language extensions, and for choosing exactly which dialect we accept. It's also responsible for deciding which optimizations to use. This fits in all of those ways.
Moreover, again, -Dfoo won't appear in --help, so, from a user's perspective, is undiscoverable. In the event that they do discover it somehow, there's no documentation attached to the flag. I am not aware of any switches built into clang that rely on -D. If you really want to do it this way, can you point me to prior art? ================ Comment at: lib/Headers/__clang_cuda_vector_types.h:81 @@ +80,3 @@ + : x(__x), y(__y), z(__z) {} + __attribute__((host, device)) explicit dim3(uint3 __a) + : x(__a.x), y(__a.y), z(__a.z) {} ---------------- Huh, apparently we do want to use the reserved namespace? If so, this logic applies very strongly to a -D, which is going to be far more user-visible than the arg names here. ================ Comment at: lib/Headers/__clang_cuda_vector_types.h:83 @@ +82,3 @@ + : x(__a.x), y(__a.y), z(__a.z) {} + __attribute__((host, device)) operator uint3(void) { return {x, y, z}; } +}; ---------------- If I'm understanding correctly, you're saying that if we have struct dim3 { dim3(unsigned, unsigned, unsigned); dim3(uint3); }; void foo(dim3); that the call uint3 x; foo(x); is ambiguous, because it could call either dim3 constructor overload? That is bizarre, but if so, do we need the dim3(uint3) constructor at all? http://reviews.llvm.org/D18051 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits