[PATCH] D18328: [CUDA] Add option to mark most functions inside <complex> as host+device.

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 21 14:42:42 PDT 2016


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





More information about the cfe-commits mailing list