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: > rnk wrote: > > 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. > > What if we had a catchall nvcc quirks mode flag similar to > > -fms-compatibility? We probably don't want a super fine grained LangOpt > > like this. > 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. > What if we had a catchall nvcc quirks mode flag similar to -fms-compatibility?
I think we midair'ed on this. See above comment about turning this flag on by default -- calling this "nvcc compat" wouldn't quite be right. We could certainly have a broader flag, but I'm not sure at the moment what else would reasonably go in with this one. http://reviews.llvm.org/D18328 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
