alpaka: OpenMP 5 accelerator does not compile with ICC

The ExecCpuOmp4 / AccCpuOmp4 does not compile with ICC because: ... called in "omp target" region must appear in prior "omp declare target" pragma. This affects at least core::mapIdx, block::sync::syncBlockThreads and all the accelerator functions that can be called within a kernel. GCC compiles this correctly and does not even issue a warning (vioalting the standard). This is reasonable because it currently only supports CPU targets which does not require to build for additional back-ends.

The problem is, that the omp declare target syntax is so verbose that it can not be represented by a simple annotation in front of the functions but requires #pragma omp declare target and #pragma omp end declare target after the functions.

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 17 (15 by maintainers)

Commits related to this issue

Most upvoted comments

It appears we would need to set the appropriate compiler flags […]

If it is only about compiler flags, then this is technically not an issue: Alpaka’s cmake configuration does ATM not set the compiler flags for OpenMP5/OpenACC for any compiler completely (it does add -fopenmp for GCC/Clang, which should also be part of with Intel). README_OMP5.md has some information about the required flags for GCC, Clang and some others. Currently, these need to be added manually by the user. This also applies to Intel, i.e. if this is regarded as an issue, the fix would be to add the Intel flags to that file.

Adding complete cmake support for offloading, which entails an additional option to select the target, would be a different issue. Is there any work being done on adding support for this directly to cmake?

@jkelling Do you know whether this is still a problem?

No idea if the new OpenMP 5 backend works with ICC. I never tested that.

However: The initial issue would be a compiler bug at least since OpenMP 4.5 as these functions are inline. Separable compilation is not supported by the new backend, which kinda addresses a potential related issue as “resolved—won’t fix”.