Intel LLVM OpenMP detection

Hello!

This is not an issue with Codeplay plugins themselves but rather with IntelLLVM installation in oneAPI. However, it is a related issue since IntelLLVM is required for Codeplay plugins.

When using oneAPI 2023.0.0 or 2023.1.0 and initializing the environment with source /opt/intel/oneapi/setvars.sh --include-intel-llvm, the clang and clang++ do not know about the correct include paths for OpenMP:

$ cat test.cpp 
#include <omp.h>

int main()
{
}
$ clang++ -fopenmp test.cpp  
test.cpp:1:10: fatal error: 'omp.h' file not found
#include <omp.h>
         ^~~~~~~
1 error generated.
e$ clang++ --version
Intel(R) oneAPI DPC++/C++ Compiler 2023.1.0 (2023.1.0.20230320)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/intel/oneapi/compiler/2023.1.0/linux/bin-llvm

Other than that, the OpenMP installation is quite functional, and providing the path to headers manually helps:

$ clang++ -fopenmp test.cpp  -isystem/opt/intel/oneapi/compiler/latest/linux/compiler/include/ && echo ok
ok

Since it’s not unlikely that people might want to use oneAPI for NVIDIA/AMD together with OpenMP, having a smoother experience (i.e., autodetection of include path for the bundled headers when -fopenmp flag is used) would be nic.

Thanks for the report. This doesn’t look like a specific Nvidia/AMD backend issue with the DPC++ compiler, in particular it’s unclear from the command line arguments what you are trying to compile in relation to this.
Can you give us some background on what you are trying to do, and we can see what is possible?
I notice a mention of openMP in there for example, I’m not sure if you are trying to use that.

Thanks for the report. This doesn’t look like a specific Nvidia/AMD backend issue with the DPC++ compiler, in particular it’s unclear from the command line arguments what you are trying to compile in relation to this.

It is not AMD/NVIDIA specific, it is related to the oneAPI-bundled IntelLLVM compiler.

As far as I can tell, this compiler is the one recommended for use with AMD/NVIDIA plugins, and not really for anything else (for Intel GPUs or for pure CPU code, it makes more sense to use icx/icpx).

So, while the issues is not GPU-related, it is related to the compiler that’s used for it and probably for little else.

But if you think there’s a better place to report the issue (Intel forums?), I can do it there.

Can you give us some background on what you are trying to do, and we can see what is possible?

Build mixed SYCL+OpenMP code for NVIDIA or AMD GPUs.

It is well tested with the custom-built intel/llvm compiler which does not require any special flags (besides -fopenmp).

It also works with oneAPI’s bundled Intel LLVM when one manually provides a path to headers: -isystem/opt/intel/oneapi/compiler/latest/linux/compiler/include.

The problem is, one would expect the compiler to automatically detect the headers bundled with that very same compiler itself.

Ok that makes more sense. At the moment the Nvidia/AMD targets in the DPC++ compiler only work with SYCL, not with OpenMP offload.

Thanks for the clarification.

I’m, however, only interested in using OpenMP for the CPU (while using SYCL for the GPU).

Apologies for the delay in responding. At the moment this isn’t functional when using the plugins for Nvidia and AMD. The technical explanation is that work is required at the LLVM IR level to make it work. We have an open issue for this but I am unsure when we might be able to work on it.

Hi Rod! Are you sure? As mentioned before, for me, adding-isystem/opt/intel/oneapi/compiler/latest/linux/compiler/include is enough to make OpenMP work on the CPU. My only concern is that this flag has to be added manually: since the headers are shipped with the compiler, I’d expect them to be detected automatically.

Maybe I misunderstood. It should work with a CPU target, but it won’t work if you try to use it on the Nvidia or AMD targets.

Oh, sorry for the confusion. I was only considering the CPU targets.

With oneAPI 2024.0, the include path changed to /opt/intel/oneapi/compiler/latest/opt/compiler/include/, but otherwise the problem and the workaround remained the same.