What makes you think printf is an internal CUDA keyword? It is a library function, just like it is in native C. You include the header, the toolchain automagically overlays the prototype with a CUDA version, and the runtime device and host functions needed to support printf get “silently” included into the code emitted by nvcc. Just like if you were programming in native C.
“printf” is not a keyword in CUDA, nor is it in C/C++ on which CUDA is modelled. It is a library function that requires a prototype which is supplied by a header file, and thus inclusion of that header file. Similarly, inclusion of stdlib.h is required when using “malloc”, again just like in C. By contrast threadIdx is part of the core language. The inclusion of host header files has been around in CUDA from the start, except it wasn’t always visible. math.h for example is being pulled in by one of the CUDA header files. My understanding is that the use of host header files is helpful in providing the consistency required for the tight integration of host and device code that CUDA offers.
Ok, but “texture” is a sort of a reserved word in cuda, isn’t it?
I’m just recovering from a stupid error of moving texture references from header to an object file and admire how nvidia forced the texture<,> template to link statically, against all c++ rules.
So before sending a file to gcc, you do some “nvidia” preprocessing, yeah?, and preceed “texture” with the c++ static keyword and get rid of any "extern"s. Yes, it works!
If you don’t belive texture is a CUDA keyword, try this:
struct texture {};
int main()
{
}
In a similar way printf should be declared somewhere as a device function OR the user guide should
inform the user that they should include standard header files.
As it is now, printf is another “magic” cuda “keyword”.