[Clang][OpenMP] Offloading entry for declare target variable is incorrect: the address is invalid

[vzakhari]

Reproducer:

struct ExecutionEnvironment {
  char *envp{nullptr};
  int listDirectedOutputLineLengthLimit{79};
};
#pragma omp declare target
ExecutionEnvironment env;
#pragma omp end declare target

clang++ dt.cpp -std=c++17 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -fopenmp -fvisibility=hidden -fopenmp-cuda-mode --offload-arch=sm_70 -c:

error: Offloading entry for declare target variable env is incorrect: the address is invalid.

I wonder what limitation I am hitting here. In addition, it compiles well if I comment out any of the members of the struct.

[llvmbot]

@llvm/issue-subscribers-openmp

Author: Slava Zakharin (vzakhari)

Reproducer: ``` struct ExecutionEnvironment { char *envp{nullptr}; int listDirectedOutputLineLengthLimit{79}; }; #pragma omp declare target ExecutionEnvironment env; #pragma omp end declare target ```

clang++ dt.cpp -std=c++17 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -fopenmp -fvisibility=hidden -fopenmp-cuda-mode --offload-arch=sm_70 -c:

error: Offloading entry for declare target variable env is incorrect: the address is invalid.

I wonder what limitation I am hitting here. In addition, it compiles well if I comment out any of the members of the struct.

[jhuber6]

Best guess is that the non-static initializer breaks the OpenMP handling somehow, see https://godbolt.org/z/6394f4Prr. Unfortunately I can't tell you why this is just looking at it. I'd think that we should be able to support this given that the data is constant initialized on both sides.

[vzakhari]

Thank you! It will be great to have it fixed, but I can also use the workaround that you suggested.

[jhuber6]

Thank you! It will be great to have it fixed, but I can also use the workaround that you suggested.

If you can initialize this manually I'd recommend that as well without relying on the global constructor. Although OpenMP offloading is perfectly capable of handing arbitrary global constructors on the device, the extra kernel launch is something like 1-5 microseconds of latency you could avoid otherwise.

[jhuber6]

Also, it seems if you swap the order to where the pointer is after the integer this doesn't throw an error either.

[vzakhari]

Also, it seems if you swap the order to where the pointer is after the integer this doesn't throw an error either.

Good finding! It looks like the issue is in the uninitialized padding automatically inserted at the end. If I add pad and initialize it to zero, it passes: https://godbolt.org/z/bGj1rE39Y