...(93): error: more than one instance of overloaded function "lerp" matches the argument list:
function "std::lerp(float, float, float) noexcept" (declared at line 1911 of /usr/include/c++/11/cmath)
function "lerp(float, float, float)" (declared at line 1226 of .../helper_math.h)
argument types are: (const float, const float, const float)
auto x0 = ::lerp(a, b, relPos.x);
The above error happens on Linux when compiling with compute architecture 8.0 but not 6.1. It also doesnāt happen on Windows.
On Linux, removing the lerp(float,float,float) definition from helper_math.h solves this. On Windows it causes compilation to fail.
The Linux behaviour seems like an error, since ::lerp shouldnāt be resolved as std::lerp.
I tried it with SDKs 12.4 and 12.8.
Anyone encountered this? Any idea how to bypass it except for different code for Windows and Linux?
I understand, though this looks to me like a problem on the compiler side, so āfix your codeā feels both condescending and wrong. I think it would be better if NVIDIA fixed is own code.
it looks to me like you have 2 candidates on the linux side (because one is coming from linux system headers, which I donāt necessarily expect to match windows system headers.)
what is the problem on the compiler side? Are you referring to this:
Can you provide a short, complete example of the issue?
I tried this on CUDA 12.8.1, but that did not show an issue:
$ nvcc -arch=sm_80 -I. -dc test2.cu -std=c++20
test2.cu(10): error: more than one instance of overloaded function "lerp" matches the argument list:
function "std::lerp(float, float, float) noexcept" (declared at line 1911 of /usr/include/c++/11/cmath)
function "lerp(float, float, float)" (declared at line 1)
argument types are: (const float, const float, const float)
result[i] = lerp(a[i], b[i], t[i]);
^
1 error detected in the compilation of "test2.cu".
$
I have seen other situations where the device code compiler āresolvesā undecorated functions using the standard library (perhaps, unexpectedly). So itās not obvious to me that is not allowed. (I donāt know.)
If you think it is a (nvcc) bug, probably best to file a bug.
If you are looking for workarounds,
it seems like one possibility would be to include your own definition in a namespace, then call out that namespace specifically:
And, FWIW, I see the same failure using the non-namespace code, whether I compile for -arch=sm_61 or -arch=sm_80. That error doesnāt appear to be arch-dependent.
Okay, thanks. It surfaced when I first used arch 80, but it might have had to do with other defaults of the compiler. IIRC I was using C++17 at the time, so perhaps it matters there.
Anyway, I opened a bug, so Iāll wait to see what happens there and in the mean time hack this thing. Thanks for the help.