Implicit omp declare target for functions outside namespace not accepted by nvc++


I am working on adding OpenMP offloading to a C++ code. I would like to declare target a few functions since they are called in offloaded compute loops. While doing this I encountered a possible issue in the nvc++ compiler.
If I understand the standard correctly, then functions that are referenced within a function that has been declare target and that are defined in the same compilation unit are implicitly declare target too and don’t need themselves an explicit annotation. This works fine if both functions are in the same namespace. But if the referenced function is not in the same namespace I am getting following error:

NVC++-S-1073-Procedures called in a OpenMP target region must have 'omp declare target' information - a() (reproducer.cpp: 7)

Here is a minimal reproducer that fails with nvhpc 21.11 and CUDA 11.5.1:

void a() {}

namespace n {
    #pragma omp declare target
    void b() { a(); }
    #pragma omp end declare target

I am not sure if I’m missing here something, but I think above example should work.
For testing I tried to compile the same example with recent versions of LLVM and Intel oneAPI, which seems to work fine.


1 Like

Thanks for the report Omar. I don’t know the standard well enough to know what the behavior should be, but given other compilers accept the syntax, I’m assuming that ours is not correct. I added a problem report, TPR #31103, and sent it to engineering for review.


Thanks for the quick response, Mat! Will be curious what they say.



Hi Mat,

Just curious whether you have some update on this issue. I was able to reproduce it on nvhpc 22.1 too.



Hi Omar,

Sorry but 22.1 was already frozen for new check-ins before the problem was reported. Though it doesn’t look like it’s been assigned to an engineer as of yet. Depending on their queue, it could be quick or could be awhile, but unfortunately I have no way on knowing when a fix will be available.

Note that I typically update the post after a fix is available in a release,


OK thanks!