[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 26 22:08:01 PST 2019


rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

In D56411#1410598 <https://reviews.llvm.org/D56411#1410598>, @yaxunl wrote:

> In D56411#1410153 <https://reviews.llvm.org/D56411#1410153>, @rjmccall wrote:
>
> > In D56411#1406212 <https://reviews.llvm.org/D56411#1406212>, @yaxunl wrote:
> >
> > > I would like to fix the validation issue only and leave the overload resolution issue for future.
> >
> >
> > As I understand it, the "validation issue" is just that you'd like a diagnostic to be emitted when resolving the template argument in order to force SFINAE to pick a different template.  I think that's actually just the overload-resolution issue.
>
>
> Currently there are two host-ness related issues about function type template arguments:
>
> 1. when there are two or more candidates for the template argument, clang goes through host-ness based overloading resolution, which does not work properly
> 2. when there is only one candidate for the template argument, clang does not go through overloading resolution, therefore the first issue does not show up. However, clang still checks host-ness of template argument. As discussed before, clang should not check host-ness in non-evaluation or constant-evaluation context. Instead, clang should check host-ness in template instantiation.
>
>   I refer the first issue as host-ness overloading resolution issue and the second issue as host-ness validation issue. They are related but separate.
>
>   The first issue only happens when host-ness based overloading resolution is used. For applications which can be compiled with nvcc, this cannot happen, therefore it is less common and less urgent.
>
>   The second issue can happen to applications which can be compiled with nvcc, therefore is more imminent.
>
>   Fixing the second issue is relatively straightforward. It does not need to introduce new AST types for host-ness. Also it is orthogonal to fixing the first issue.


Okay, I understand now.  LGTM.


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

https://reviews.llvm.org/D56411





More information about the cfe-commits mailing list