I embedded in my project some ~.cu files.
In some of them i need to declare and implement my global functions with an inline to call them somewhere else.
I do this like here:
inline global
void devUpdateOutpDelta(
float *pNeuronsX,
float *pErrorX,
float *pOutput)
{
int x = blockIdx.x * blockDim.x + threadIdx.x;
pErrorX = pOutput - pNeuronsX;
}
If I dont use inline i will get an:
multiple definition of … error
Same problems as known from C/C++ source code. But there I dont get these nasty compiler-warnings?!
Is this a nvcc bug?
It is technically impossible to inline a [font=“Courier New”]global[/font] function (aka a kernel), because execution has to be switched from host to device at some point. If you are looking for a way to declare a function that can be inlined either on the host or the device, [font=“Courier New”]hostdevice[/font] is your friend.
I’m not sure what you’re saying. I thought you said that if you don’t inline the errors are “normal” ones and not nasty ones:
If I dont use inline i will get an:
multiple definition of ... error
Same problems as known from C/C++ source code. But there I dont get these nasty compiler-warnings?!
I mean in normal c++ code i would get same "multiple definition of … error"s if i DON’T inline functions which will get used in several source files.
So i dont understand why i get warnings which do not make any sense. Furthermore i dont know any methods to avoid an inline, because i need that functions in other source files too.
Why do you need multiple definitions? Just distribute the function header to all the files that need it; can’t you?! The following file compiles without errors. Notice that g() isn’t implemented in this file, it must be implemented in another file.
file: ttt.cu
global void g();
main(){g<<<1,1>>>();}
compile command: nvcc -c ttt.cu
HOWEVER,
If you must have multiple definitions for a good reason, use the static keyword instead of inline. A ‘static’ function is only visible in one file(“translation unit”) and nowhere else, so “multiple copies” in several files won’t conflict.
I should point out that incorrect use of these keywords will lead to (compiled) code blowup. It’s important to know what they’re actually doing. Having proper header files prevents unnecessary blowup.