[PATCH] D114326: Update the list of CUDA versions up to 11.5

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D114326#3154228 <https://reviews.llvm.org/D114326#3154228>, @mojca wrote:

> Somewhat off-topic from a discussion earlier in the thread.
> What's the purpose of the following code then if users are supposed to explicitly specify the `-L` flag anyway?

Good point, it is indeed unused.

> clang++.exe hello.cu -o hello --cuda-path="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.4" -l cudart -L "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.4/lib/x64"
>
>   Also, it's probably destined to lead into issues if the user needs to manually specify the library path, while the cuda path is determined automatically.

Yup. That's why I'm a strong proponent of not autosearching beyond the canonical location and ask users to explicitly specify the CUDA SDK they want to use. 
In case of the canonical location on windows, users can then use `-L "$CUDA_PATH%/lib/x64"` everywhere.

As for automatically adding linker flage, it's been considered before and the conclusion was that it's not very useful.
Unlike nvcc, clang's linking phase has no idea about CUDA and we can not assume that any of the objects or libraries we're linking with have anything to do with CUDA. 
It is useful in a niche case when one compiles source-to-executable in one clang invocation and where we do know that we're dealing with CUDA, but this is not how clang is used most of the time, when compilation and linking are done separately.

So, yes, you could automatically add linking flags in your example, but it's not feasible to do so for the linking phase in general. It would also introduce inconsistency in clang's linking phase behavior and would lead to questions -- why things work with `clang hello.co`, but not with `clang -c hello.cu; clang hello.o` ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114326