rnk 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.
I don't really like include_next wrapper headers, but adding a pragma spelling
of the cuda device attributes might be nice. There would still be issues with
the streaming operators, though.
================
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.
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.
http://reviews.llvm.org/D18328
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
