tra added a comment.
In http://reviews.llvm.org/D18328#379824, @rsmith wrote:
> 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.
We'll still need some filtering as not everything inside <complex> should be
`__host__` `__device__`.
================
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>,
----------------
rsmith wrote:
> I don't think it's reasonable to have something this hacky / arbitrary in the
> stable Clang driver interface.
What would be a better way to enable this 'feature'? I guess we could live with
-Xclang -fcuda-allow-std-complex for now, but that does not seem to be
particularly good way to give user control, either.
Perhaps we should have some sort of --cuda-enable-extension=foo option to
control CUDA hacks.
http://reviews.llvm.org/D18328
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
