Hi,
clangd doesn’t seem to find omp.h which results in lots of diagnostics errors. I tried adding “include/omp.h”, <omp.h> to the CanonicalIncludes.cpp file but that didn’t seem to make a difference. Can someone give me some pointers on how to make clangd recognize omp.h?
Regards,
Daan
Installing the openmp package on Arch Linux made clangd find the omp.h header (/usr/include/omp.h). Is it possible to make clangd find gcc’s omp.h as well (located at /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include/omp.h on my system)?
Regards,
Daan
As long as /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
is specified in your compile command, clangd should be able to find that file.
I believe clang does not pickup gcc’s OpenMP header by default and actually requires a bit of a different setup. I think I’ve ran into that before, but don’t remember the details…
Are you using compile_commands.json produced for gcc? Could you share the project (if it’s open-source) or make a small repro?
Sorry for the late response.
As long as /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
is specified in your compile command, clangd should be able to find that file.
True, but gcc does not need that include path. So if you have compile_commands.json generated for gcc, clangd (or any clang-based tool) won’t find omp.h
Asking the users to specify the -I to the gcc internal header is definitely not a nice UX, for the same reasons we don’t ask to specify a path to the C++ STL and auto-detect it instead.
(It’s a bit different with omp.h, since it’s actually part of the gcc internal headers and adding those to include dirs is not a good idea. I assume that’s the reason we don’t have auto-detection in the first place.)
So it seems we have a few options:
- tell clangd to use the third-party, but not gcc-internal, OpenMP header.
- ship the LLVM’s OpenMP alongside clang/clangd. (Maybe it’s already included in the llvm releases)
- figure out a way to make clang detect compatible GCC’s omp.h header without adding the whole internal gcc include dir to search paths.
The last option is certainly the most user-friendly one, but it’s probably too much work. I’d go with documenting this particular problem and providing one or two ways to workaround it.