rsmith added inline comments.

================
Comment at: lib/Sema/SemaCUDA.cpp:464-465
@@ +463,4 @@
+// <complex> without passing -fcuda-allow-std-complex.
+// TODO: Output a nvcc-compat warning if you try to use a non-constexpr 
function
+// from <complex> -- nvcc only lets you use constexpr functions.
+bool Sema::declShouldBeCUDAHostDevice(const FunctionDecl &FD) {
----------------
jlebar wrote:
> rsmith wrote:
> > Does nvcc do this "`constexpr` implies `__host__ __device__`" thing only 
> > for functions declared within <complex>, or for all functions?
> > 
> > Another alternative strategy: a wrapper `<complex>` header that does this:
> > 
> >     #include // ... union of includes from libc++ and libstdc++ <complex>
> >     #define constexpr __host__ __device__ constexpr
> >     #include_next <complex>
> >     #undef constexpr
> > Does nvcc do this "constexpr implies __host__ __device__" thing only for 
> > functions declared within <complex>, or for all functions?
> 
> All functions.  Although std::complex is the main use I've observed.
> 
> > Another alternative strategy: a wrapper <complex> header that does this:
> 
> That one is quite clever, although I'm not sure about enumerating all of the 
> includes from the headers.  I guess that should be reasonably stable...
> 
> I think I would like to get full complex support, though, if we can agree on 
> a path towards that.  The current limitation is silly, it seems clear that 
> people want this, and the constexpr thing gives you but a shadow of the 
> actual library.
Supporting a "`constexpr` implies `__host__ __device__`" feature for all 
functions seems a lot cleaner than the approach taken by this patch, and will 
presumably improve NVCC compatibility in other cases too (though perhaps 
they're quite rare). This seems like a very odd pair of features to link in 
this way, but if we're going to have something weird like this to support 
existing NVCC-targeting code, using the same approach may be better. This would 
also mean we would not be further extending NVCC's extension.


http://reviews.llvm.org/D18328



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

Reply via email to