[PATCH] D108247: [CUDA] Improve CUDA version detection and diagnostics.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D108247#3025415 <https://reviews.llvm.org/D108247#3025415>, @tambre wrote:

>> Another workaround would be to place a fake /usr/lib/cuda/include/cuda.h with something like this:
>
> My CMake CI bot [[ https://open.cdash.org/test/498767666 | encountered `cmath` template errors ]] after I manually symlinked `/usr/lib/cuda/include` to `/usr/include`, though that solved the version detection.
> Adding a shim like the one you show fixes everything and compiling works.
>
>> Clang does rely on very particular ordering of includes, so having CUDA headers in a location clang does not expect will lead to issues sooner or later.
>
> Having the headers in the system-wide `/usr/include` shouldn't be a problem though, right?
> I'm not quite sure why simply having `/usr/lib/cuda/include` → `/usr/include` symlink breaks as seen on my bot.

If you look at the logs of the broken build you will see that `/usr/lib/cuda/include/` appears fairly early in the search path, before the standard library C++ headers.
Symlinking it to /usr/include places a lot of other includes and that breaks the include order for the C++ library which has its own assumptions and requirements.

> Prior to this an empty `/usr/lib/cuda/include` and Clang finding them through the regular include search path worked.

It's possible that the CUDA headers themselves do not need to be placed in the include path that early. We do need cuda_wrappers to be there, but at the moment I do not recall why we ended up placing cuda/include there as well. The fact that it worked for you with the empty directory suggests that it may not be necessary.

If we move cuda includes down to where /usr/include is in the search list, it should allow symlinking it to /usr/include.
I'll check whether that's feasible.

>> If the headers are not available where --cuda-path points clang to, I'm not sure what clang is supposed to do. Second-guessing explicit user input is not a good idea in general.
>
> I agree that second-guessing is bad, but expecting it to be available in the include search path otherwise seems reasonable.

The issue with the include search path is that it's something that's not readily available at the clang driver level at the point in time  where we need to detect cuda version.
The driver does construct the include arguments for cc1 invocations, but all that happens quite a bit later after CUDA detection is done.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108247/new/

https://reviews.llvm.org/D108247