I want to thank some of the helpful comments.

I believe I have answers to most of the questions I had previously, and want to write a short summary here.

To map data stored in embedded pointers inside a struct/class such as

struct Dataset {
    int len = 0;
    float *data = nullptr;
    Dataset() {}
    Dataset(int len0, int *data0) {...}
} readonlydata, readwritedata;

the following omp pragma works on most compilers (gcc 11 to 14, clang 16+)

map(to: readonlydata) map(to: readonlydata.data[0:readonlydata.len]) \
map(tofrom: readwritedata) map(tofrom: readonlydata.data[0:readonlydata.len])

The data pointer must be separately mapped in order to pass those to the device.

this was mostly inspired by the "Deep-Copy" OpenACC example shared by Mat Colgrove

https://developer.download.nvidia.com/assets/pgi-legacy-support/Deep-Copy-Support-in-OpenACC_PGI.pdf

It appears that OpenMP also supports using variables as array length at runtime.

Based on the OpenMP 5.1 examples, another way to map such nested dynamic data is to use declare mapper(), which does not apply to individual variable, but applies to the struct type (typedef)

typedef struct Dataset dataset;
#pragma omp declare mapper(dataset ds) map(ds, ds.data[0:ds.len])

Unfortunately, it appears that declare mapper() clause is currently not supported in either gcc or nvc.

Now, regarding gcc, clang and nvc, the completeness and robustness of their OpenMP GPU offloading features are quite uneven and overall buggy.

Among these 3 compilers, nvc is the most robust and also offers the highest gpu speed after offloading. However, it is only supported on Linux. gcc/clang can build on Mac/Windows, but both produced slow/unoptimized binaries. gcc-12 is relatively the more stable one, but the binary is also quite slow. gcc-11 can build my code, but does not run properly on some GPUs; gcc-13/14 both can build, but won't run. I have found a number of regressions that were related to those error messages.

Some commonly seen gcc error messages when building nvptx with gcc-11 to 13

• if g++ reports a linking error that "undefined symbol sinf" or cosf or sincosf, it can be resolved by adding -foffload="-lm" in the linking command
• if g++ (on Ubuntu 22.04, but not 24.04) reports a linking error that x86_64-linux-gnu-accel-nvptx-none-gcc-13: fatal error: cannot read spec file ‘libgomp.spec’: No such file or directory this is a known gcc bug, one can link the /usr/lib/gcc/x86_64-linux-gnu/12/accel folder to gcc/13
• if g++ reports an error Value 'sm_30' is not defined for option 'gpu-name' this is because of the cuda version of your system, need to update to 12.x. Adding -foffload="-march=sm_35" won't help
• gcc-13 and gcc-14 has a known regression for handling nested dynamic arrays inside struct, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867, it produced an error libgomp: cuCtxSynchronize error: an illegal memory access was encountered libgomp: cuMemFree_v2 error: an illegal memory access was encountered libgomp: device finalization failed
• gcc-12 can produce valid nvptx binary, but the binary is really slow. there are two problems of gcc-12 produced nvptx binaries
  • in gcc-12/13, the total launched block number ignores user's num_teams() or OMP_NUM_THEAMES setting, and is capped to a small number, which is severely underutilizing the GPU hardware; I suspect that it is related to this fix (maybe a regression?): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875
  • the produced kernel is unoptimized and uses too many registers. In my case, gcc uses 150+ registers compared to 60ish for nvc compiled binary.
• so far, I haven't been able to make gcc amdgcn offloading to work - gcc-12/13 can compile this binary, but it always gives libgomp: Offload data incompatible with GCN plugin (expected 3, received 2) libgomp: Cannot map target functions or variables (expected 1, have 4294967295) error when running.

as of now (Jan of 2025), gcc's GPU offloading is still quite buggy and unoptimized. nvc is the quicker solution to get the code to build and run.