rsmith added a subscriber: rsmith.
rsmith added a comment.
I would much prefer for us to, say, provide a <complex> header that wraps the
system one and does something like
// <complex>
#pragma clang cuda_implicit_host_device {
#include_next <complex>
#pragma clang cuda_implicit_host_device }
or to provide an explicit list of the functions that we're promoting to
`__host__` `__device__`, or to require people to use a CUDA-compatible standard
library if they want CUDA-compatible standard library behaviour.
================
Comment at: include/clang/Driver/Options.td:383-384
@@ -382,2 +382,4 @@
HelpText<"Enable device-side debug info generation. Disables ptxas
optimizations.">;
+def cuda_allow_std_complex : Flag<["--"], "cuda-allow-std-complex">,
+ HelpText<"Allow CUDA device code to use definitions from <complex>, other
than operator>> and operator<<.">;
def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group<i_Group>,
----------------
I don't think it's reasonable to have something this hacky / arbitrary in the
stable Clang driver interface.
================
Comment at: lib/Sema/SemaCUDA.cpp:479-481
@@ +478,5 @@
+ return false;
+ StringRef Filename = FE->getName();
+ if (Filename != "complex" && !Filename.endswith("/complex"))
+ return false;
+
----------------
I don't think this works: the standard library might factor parts of <complex>
out into separate header files. For instance, libstdc++ 4.4 includes the TR1
pieces of <complex> in that way.
http://reviews.llvm.org/D18328
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
