jlebar added inline comments. ================ 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>, ---------------- jlebar wrote: > tra wrote: > > 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. > > I don't think it's reasonable to have something this hacky / arbitrary in > > the stable Clang driver interface. > > This is an important feature for a lot of projects, including tensorflow and > eigen. No matter how we define the flag, I suspect people are going to use > it en masse. (Most projects I've seen pass the equivalent flag to nvcc.) At > the point that many or even most projects are relying on it, I'd suspect > we'll have difficulty changing this flag, regardless of whether or not it is > officially part of our stable API. > > There's also the issue of discoverability. nvcc actually gives a nice error > message when you try to use std::complex -- it seems pretty unfriendly not to > even list the relevant flag in clang --help. > > I don't feel particularly strongly about this, though -- I'm more concerned > about getting something that works. An alternative wrt the flag is to enable it by default. This would be somewhat consistent with existing behavior, wherein we make most std math functions available without a special flag, even though they're not technically host-device. The main difference here is that there we're matching nvcc's default behavior, whereas here we're actually going further than nvcc -- nvcc by default doesn't let you touch std::complex from device code at all, and with a flag, you can touch its *constexpr* functions. Which is not actually very much.
Nonetheless, since the user-visible effect is consistent with our approach of making std math stuff available, and since this shouldn't make us reject code nvcc accepts, I'd be more OK hiding the flag to turn it off. http://reviews.llvm.org/D18328 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
