I have written an amazing kernel which will bring me fame and fortune - if I can only get it to compile with NVRTC:
#include <stdio.h>
__global__ void do_stuff() { }
I would have hoped that system headers should be recognized by the (runtime) compiler, just like a regular compiler, and that this would "just work" (modulo any printf-specific machinery). Alternatively, if it didn't work, I would have expected an error message about stdio.h
's source not made available with the "program creation" API call (nvrtcCreateProgram()
), since I'm passing NULL
and NULL
as its last two arguments.
However, what I get is the following:
/usr/include/stdio.h(33): catastrophic error: cannot open source file "stddef.h"
This seems strange to me. It means that the runtime compiler is able to look inside system headers, but is not able to find stddef.h
, like nvcc or the host side compiler are able to.
Why is this happening, and what is the idiomatic/recommended workaround?
Note: I'd like a workaround which would be cross-platform, not just work on my individual machine.
An additional approach is taken in the "JITify" library which Robert Crovella has graciously reminded me of. While this doesn't seem to be documented very well, Jitify pre-includes processed snippets of various headers it sees fit to. In particular for
<climits>
/<limits.h>
:for
stddef.h
:and for
stdio.h
:If you include those strings as headers, with the appropriate names as keys, it is likely your kernel will compile.
In fact, one could form header files out of these and other mini-headers in
jitify.hpp
, to use in non-NVRTC kernel compilation. That might be useful too.One last point: The constants above do not specify a
__device__
execution space. So, either you add__device__
in there, or tell the compiler to assume functions are intended for execution on the device only, unless otherwise specified; that's the--device-as-default-execution-space
NVRTC compiler option.