[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Michael Liao via Phabricator via cfe-commits]

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