Hi there, If you have LLVM 18 and 19 at your system, hip uses LLVM 19 no matter the LLVM_SLOT used. Reproducible: Always Steps to Reproduce: 1. Install LLVM 18 and 19 2. Build hip 3. Observe the build log Actual Results: hip is built with clang 19 Expected Results: hip being built with clang 18 Because of this problem, you are likely unable to use any hip project (hipSPARSE, hipBLAS) because will conflict with ROCM 6.1 packages with LLVM 19. I think this is resolved in later ROCM packages.
Created attachment 912565 [details] build.log
# equery uses hip [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-util/hip-6.1.2: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + hip : Build HIP runtime + + llvm_slot_18 : Use LLVM 18. - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) + + video_cards_amdgpu : Build for AMD platform - - video_cards_nvidia : Build for Nvidia platform
Thanks for the report. HIP should adopt to the LLVM_SLOT mechanism.
Interestingly enough, dev-util/hip contains no hip code, except for tests and hipRTC_header compiled into machine code. What you see in the log is your systemwide compiler (which can also be g++) and for hipRTC_header you will see clang-18 and /usr/lib/llvm/18/bin/llvm-mc. And for tests it uses hipcc, which inside uses clang-18 too. So there is nothing to fix: LLVM_SLOT applies to GPU code (failure to apply it would result in linking issues in other packages, because LLVM machine code is never forward-compatible between releases), CPU code uses compiler of your choice.
(In reply to Sv. Lockal from comment #4) > Interestingly enough, dev-util/hip contains no hip code, except for tests > and hipRTC_header compiled into machine code. Strictly speaking dev-util/hip[test] contains hip code :) > So there is nothing to fix: LLVM_SLOT applies to GPU code (failure to apply > it would result in linking issues in other packages, because LLVM machine > code is never forward-compatible between releases), CPU code uses compiler > of your choice. Exactly. dev-util/hip provides libamdhip64.so which is a library runs on CPU (contain methods to interact with GPU), so it's OK to use any C++ compiler to compiler its C++ source code. clang-19 is fine. LLVM version only matters when compiling GPU kernels -- because that engages rocm-device-libs, which contains bitcode (compiled LLVM IR), and rocm-comgr, which calls LLVM C++ api. They both interacts with LLVM internal stuff (ABI and API).