rsmith added a subscriber: rsmith.

================
Comment at: include/clang/AST/ExprCXX.h:175
@@ +174,3 @@
+  void setConfig(CallExpr *E) {
+    setPreArg(CONFIG, E);
+    setInstantiationDependent(isInstantiationDependent() ||
----------------
Can you assert that the argument is only set once here? (If we set it to 
something instantiation-dependent and then to something that isn't 
instantiation-dependent, we'd compute the wrong instantiation-dependence flag.) 
This function should only be called by the normal constructor and by people who 
called the `EmptyShell` constructor.

================
Comment at: test/SemaCUDA/kernel-call.cu:27
@@ -26,1 +26,3 @@
+
+  g1<<<undeclared, 1>>>(42); // expected-error {{use of undeclared identifier 
'undeclared'}}
 }
----------------
jhen wrote:
> Thanks for bringing this up. While trying to find tests that dealt with each 
> dependence individually, I came to realize that value and type dependence 
> should not be set for the CUDAKernelCallExpr node because it's value is 
> always void. So, I removed the propagation of those two dependencies.
> 
> Then, while looking for a test that could handle the parameter pack 
> information, I realized that it was opening up a whole new can of worms and 
> that the triple-angle-bracket syntax does not currently support variadic 
> templates. I decided that parameter packs should be handled as a separate 
> bug, so I removed them from this patch.
> 
> The instantiation dependence propagation is still valid, though, because it 
> just represents whether a template parameter is present anywhere in the 
> expression, so I left it in. Correctly tracking instantiation dependence in 
> enough to fix the bug this patch was meant to fix, so I think it is the only 
> change that should be made in this patch.
What happens if an unexpanded pack is used within the kernel arguments of a 
CUDA kernel call? Do we already reject that? Are there tests for that somewhere?


http://reviews.llvm.org/D15858



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to