Missing implicit include paths with clang-tidy

[julien-j]

Hello, I believe there is an issue in the way clang-tidy, as provided by oneAPI, handles implicit include paths.

Given this file:

// test.cpp
#include <omp.h>

A run of `icpx -c test.cpp` passes without issues, but a run of `/opt/intel/oneapi/compiler/latest/bin/compiler/clang-tidy --checks=* test.cpp` fails with the following error:

Error while processing test.cpp.
test.cpp:1:10: error: 'omp.h' file not found [clang-diagnostic-error]
1 | #include <omp.h>
| ^~~~~~~
Found compiler error(s).

I tried with various combinations of -fiopenmp and -fopenmp for the same result.

If we check default include paths with `icpx -x c++ -v -c /dev/null`:

#include <...> search starts here:
/opt/intel/oneapi/dev-utilities/2026.0/include
/opt/intel/oneapi/umf/1.1/include
/opt/intel/oneapi/tbb/2023.0/env/../include
/opt/intel/oneapi/dpl/2022.12/include
/opt/intel/oneapi/compiler/2026.0/bin/compiler/../../opt/compiler/include
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/x86_64-linux-gnu/c++/15
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15/backward
/opt/intel/oneapi/compiler/2026.0/lib/clang/22/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include

 And compare with those of clang-tidy with `clang-tidy /dev/null -- -x c++ -v -c /dev/null`:

#include <...> search starts here:
/opt/intel/oneapi/dev-utilities/2026.0/include
/opt/intel/oneapi/umf/1.1/include
/opt/intel/oneapi/tbb/2023.0/env/../include
/opt/intel/oneapi/dpl/2022.12/include
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/x86_64-linux-gnu/c++/15
/usr/lib/gcc/x86_64-linux-gnu/15/../../../../include/c++/15/backward
/usr/lib/llvm-20/lib/clang/20/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include

We can see that the path `/opt/intel/oneapi/compiler/2026.0/bin/compiler/../../opt/compiler/include`, which contains omp.h, is missing from the latter.

[Sravani_K_Intel]

Thank you for reporting this issue. This behavior is expected as clang-tidy is a separate binary that doesn't inherit the Intel compiler driver's enhanced header search paths (including opt/compiler/include where omp.h resides).

At this time, we don't have plans to modify our clang-tidy to automatically detect Intel-specific paths. However, if
we receive additional reports from other customers, we can consider this as a feature request for a future release.

In the meantime, here are two recommended workarounds:

Option 1: Use a Compilation Database (Recommended)

Generate compile_commands.json from your build system, which captures the actual compiler flags:

# With CMake:
cmake -DCMAKE_CXX_COMPILER=icpx -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..

# Then run clang-tidy normally:
clang-tidy --checks=* test.cpp

clang-tidy will automatically use the include paths from the compilation database.

Option 2: Explicitly Add Intel Include Paths

For standalone files, pass Intel's include paths directly:

clang-tidy --checks=* test.cpp -- \
-I/opt/intel/oneapi/compiler/latest/opt/compiler/include \
-I/opt/intel/oneapi/compiler/latest/lib/clang/22/include

[julien-j]

Thanks for the workarounds but I believe it is not a valid solution for this problem The path to `/opt/intel/oneapi/compiler/2026.0/bin/compiler/../../opt/compiler/include` is not visible anywhere, especially not in compile_commands.json, because it is an internal, implicit, path of ICX. Consequently it also makes no sense to explicitly pass it in the arguments of Intel's clang-tidy.

Since Intel provides a version of clang-tidy alongside ICX it is expected that they work together, otherwise what's the point of providing clang-tidy at all?

[Sravani_K_Intel]

It is reasonable to expect Intel's clang-tidy to work seamlessly with ICX-compiled code without requiring manual configuration of implicit include paths. The core issue is that clang-tidy doesn't automatically query ICX for its implicit include paths (like the path to `omp.h`), and these paths don't appear in compilation databases because they're internal to the compiler driver. I raised a request to implement this.