Artem-B wrote: > Therefore, the following code would cause a deprecation warning during host > compilation, even though val is only used as part of a device function:
This is where we may need help from @zygoloid. > __attribute__((device)) std::enable_if<(val() > 0), int>::type fun(void) Here `val()` is evaluated in global context as it does not have a caller function. As such, overload resolution picking a host function during host compilation is a WAI, even if it happens to be part of a GPU-side function declaration. In this case, function overload fails, and the patch tries to suppress such an error. If we are adding a special case for handling overloads, perhaps a better approach would be to consider inferring the caller context from the enveloping function declaration attributes, and allow overload resolution to pick a device function instead. It would avoid the errors you're trying to suppress, and it will arguably make things more consistent -- the function declaration will have the same signature in both host and device compilations. @zygoloid -- do you think such a change will create other issues? https://github.com/llvm/llvm-project/pull/93546 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
