hliao added a comment.

In D61458#1488981 <https://reviews.llvm.org/D61458#1488981>, @rjmccall wrote:

> In D61458#1488972 <https://reviews.llvm.org/D61458#1488972>, @hfinkel wrote:
>
> > In D61458#1488970 <https://reviews.llvm.org/D61458#1488970>, @jlebar wrote:
> >
> > > Here's one for you:
> > >
> > >   __host__ float bar();
> > >   __device__ int bar();
> > >   __host__ __device__ auto foo() -> decltype(bar()) {}
> > >
> > >
> > > What is the return type of `foo`?  :)
> > >
> > > I don't believe the right answer is, "float when compiling for host, int 
> > > when compiling for device."
> >
> >
> > So, actually, I wonder if that's not the right answer. We generally allow 
> > different overloads to have different return types.
>
>
> Only if they also differ in some other way.  C++ does not (generally) have 
> return-type-based overloading.  The two functions described would even mangle 
> the same way if CUDA didn't include host/device in the mangling.
>
> (Function templates can differ only by return type, but if both return types 
> successfully instantiate for a given set of (possibly inferred) template 
> arguments then the templates can only be distinguished when taking their 
> address, not when calling.)
>
> I think I've said before that adding this kind of overloading is not a good 
> idea, but since it's apparently already there, you should consult the 
> specification (or at least existing practice) to figure out what you're 
> supposed to do.


BTW, just check similar stuff with nvcc, with more than one candidates, it 
accepts the following code

  float bar(); // This line could be replaced by appendig `__host` or 
`__device__`, all of them are accepted.
  __host__ __device__ auto foo() -> decltype(bar()) {}

however, if there are more than one candidates differenct on the return type 
(without or with CUDA attibute difference), it could raise the error

  foo.cu(4): error: cannot overload functions distinguished by return type alone

it seems to me that that's also an acceptable policy to handle the issue after 
we allow different-side candidates in type-only context.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61458/new/

https://reviews.llvm.org/D61458



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to