You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying the generator system with some vector operations. In OpenCL the operators on vector types are part of the language, so no issue there, but to use them in CUDA I need to include "helper_math.h".
However, in cuda.py the whole generated code is wrapped in "extern C", and this generates a plethora of naming errors with this specific header file.
To make everything work I set no_extern_c to True in cuda.py, and added an "extern C" statement only around the kernel. This solution would require the user, to my understanding, to use "extern C" for every kernel, breaking compatibility with current code and making everything more cumbersome.
The text was updated successfully, but these errors were encountered:
Forcing the user to pay attention to this is, actually, the best idea, as it is already the case for the manually written code.
No change necessary for the source code, thus I close this issue.
Yeah if you explicitly give your kernel extern "C" linkage, then cuda.py will detect that and set no_extern_c to True for you. But indeed, apart from looking for whether there is a substring containing 'extern "C"' I believe there isn't too much we can do. Well, it may be better to not play the guessing game and (unlike pycuda) not wrap it all in extern "C", it's just a little bit more user-friendly for small kernels.
I was trying the generator system with some vector operations. In OpenCL the operators on vector types are part of the language, so no issue there, but to use them in CUDA I need to include "helper_math.h".
However, in cuda.py the whole generated code is wrapped in "extern C", and this generates a plethora of naming errors with this specific header file.
To make everything work I set no_extern_c to True in cuda.py, and added an "extern C" statement only around the kernel. This solution would require the user, to my understanding, to use "extern C" for every kernel, breaking compatibility with current code and making everything more cumbersome.
The text was updated successfully, but these errors were encountered: