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 cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits