tra added inline comments.

================
Comment at: clang/lib/Sema/SemaDeclCXX.cpp:15162-15170
+  bool SkipDtorChecks = VD->getType()->isArrayType();
+
+  // CUDA: Skip destructor checks for host-only variables during device-side
+  // compilation
+  SkipDtorChecks |=
+      (LangOpts.CUDAIsDevice && VD->hasGlobalStorage() &&
+       !(VD->hasAttr<CUDADeviceAttr>() || VD->hasAttr<CUDAConstantAttr>() ||
----------------
rsmith wrote:
> Is this safe? What happens if the destructor for the variable is a template, 
> and instantiating that template results in a reference to a device function? 
> Eg:
> 
> ```
> template<typename T> __device__ void f() {}
> template<typename T> struct A {
>   ~A() { f<<<>>>(); }
> };
> A a;
> ```
This is business as usual -- we catch it during host compilation, where `a` is 
instantiated.

```
h.cu:3:10: error: no matching function for call to 'f'
  ~A() { f<T>(); }
         ^~~~
h.cu:5:8: note: in instantiation of member function 'A<int>::~A' requested here
A<int> a;
       ^
h.cu:1:51: note: candidate function not viable: call to __device__ function 
from __host__ function
template<typename T> __attribute__((device)) void f() {}

1 error generated when compiling for host.
```

If it were a `__device__ A<int> a;` , then we catch it during GPU compilation 
and also complain that we can't have dynamic initializers.



================
Comment at: clang/test/SemaCUDA/default-ctor.cu:28
   InHD inhd;
-  Out out; // expected-error{{no matching constructor for initialization of 
'Out'}}
+  Out out;
   OutD outd;
----------------
rsmith wrote:
> I don't think we should accept this -- only functions that are defaulted on 
> their first declaration should get special treatment. Instead of checking for 
> `isDefaulted()` above, you should check for `!isUserProvided()` instead.
Fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94732/new/

https://reviews.llvm.org/D94732

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

Reply via email to