dev-libs/intel-neo-20.37.17906 fail with error: FAILED: bin/built_ins/x64/gen9/aux_translation_Gen9core.spv bin/built_ins/x64/gen9/aux_translation_ Gen9core.bin bin/built_ins/x64/gen9/aux_translation_Gen9core.gen Reproducible: Always
Created attachment 661801 [details] build.log
1. Could you try again now? 2. If the problem still persists, could you run the failing command (the line immediately after the one starting with FAILED; remember to cd to the build directory first) but without the '-q' argument, then post the result?
1. Same error 2. $ cd /var/tmp/portage/dev-libs/intel-neo-20.37.17906/work/compute-runtime-20.37.17906/shared/source/built_ins/kernels $ LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/intel-neo-20.37.17906/work/intel-neo-20.37.17906_build/bin /var/tmp/portage/dev-libs/intel-neo-20.37.17906/work/intel-neo-20.37.17906_build/bin/ocloc -file aux_translation.builtin_kernel -device skl -64 -out_dir /var/tmp/portage/dev-libs/intel-neo-20.37.17906/work/intel-neo-20.37.17906_build/bin/built_ins/x64/gen9 -options -cl-kernel-arg-info [0]: /var/tmp/portage/dev-libs/intel-neo-20.37.17906/work/intel-neo-20.37.17906_build/bin/libocloc.so(_ZN16SafetyGuardLinux9sigActionEiP9siginfo_tPv+0x30) [0x7f9fb29da4d0] [1]: /lib64/libc.so.6(+0x38740) [0x7f9fb27b3740] [2]: /usr/lib/llvm/10/lib64/../lib64/libclang-cpp.so.10(+0x31ac674) [0x7f9fad303674] [1] 8390 abort LD_LIBRARY_PATH= -file aux_translation.builtin_kernel -device skl -64
Okay, I have finally managed to reproduce the problem on one machine and I am beginning to suspect what is wrong. Could you try the following: 1. Re-emerge dev-util/spirv-llvm-translator. Try NEO again. 2. If that doesn't help, do the same with dev-libs/opencl-clang.
With first solution package fails again, but re-building also the second package the intel-neo finishes installation without errors. Can you tell me how did you come to that conclusion?
I feel I now have got an idea of what is going on. The scenario which triggers the problem appears to be as follows: 1. dev-libs/intel-neo gets emerged, pulling in among other things dev-libs/opencl-clang; 2. sys-devel/clang gets updated to a newer upstream version but dev-libs/opencl-clang remains untouched; 3. user attempts to update or rebuild dev-libs/intel-neo WITHOUT rebuilding or updating dev-libs/opencl-clang first. The problem is, it turns out even a theoretically minimal Clang version change ( in this case, from 10.0.0 to 10.0.1) can break opencl-clang - and to the best of my knowledge the only way for this to happen would require adding subslots to sys-devel/clang (and probably sys-devel/llvm too, just in case). Will discuss this with Project LLVM, in the meantime however the "solution" to this kind of intel-neo build failures is to manually rebuild dev-libs/opencl-clang and try again.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9c56c3f7767d7f6b9b429600b96b3e518b5dd046 commit 9c56c3f7767d7f6b9b429600b96b3e518b5dd046 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-09-24 12:08:09 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-09-24 12:11:02 +0000 dev-libs/opencl-clang:10: force rebuild on clang .0->.1 update Works around Bug #743992. Hopefully LLVM upstream will not make introducing breaking ABI changes in new patch releases a habit and such hackery will not be required in the future. Closes: https://bugs.gentoo.org/743992 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../opencl-clang/opencl-clang-10.0.0.1-r1.ebuild | 42 +++++++++++++++++++++ .../opencl-clang/opencl-clang-10.0.0.2-r1.ebuild | 43 ++++++++++++++++++++++ 2 files changed, 85 insertions(+)
As mentioned in the commit message, let's hope this is a one-time thing and we will not have to really do this on every clang update.
Thank you for solve the issue and for explanation
