ocloc crashes with LLVM 13 #204
Comments
|
This looks like an issue on IGC side, which according to build_ubuntu.md currently supports llvm 11 at production quality and llvm 12 as experimental. As I can see in IGC commit history support for llvm 13 is under development. |
|
Hi @zboszor, Please note |
Builtins throw compilation failure. So disable for now, until fixed. intel/intel-graphics-compiler#204 Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com> Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
What are the versions of the dependencies other than LLVM? Why the build is done under (x86_64) Qemu, and what additional limitations (e.g. RAM) it sets on the build environment? Can you reproduce ocloc crash without Qemu (e.g. in a docker container, if you want build to be isolated)? |
|
Traced it to llvm/llvm-project@b00cff5 and verified that reverting that commit on top of LLVM 13.0.0 avoids the ocloc crash. It seems that IGC should not pass Edit: The above allowed me to remove Edit 2: Digging further into the second crash, it appears to crash here because The three top-most symbols from libigc.so.1 appear to be: |
This is a temporary workaround until intel-graphics-compiler is fixed. intel/intel-graphics-compiler#204 git-svn-id: file:///srv/repos/svn-packages/svn@427924 eb2447ed-0c53-47e4-bac8-5bc4a241df78
This is a temporary workaround until intel-graphics-compiler is fixed. intel/intel-graphics-compiler#204 git-svn-id: file:///srv/repos/svn-packages/svn@427924 eb2447ed-0c53-47e4-bac8-5bc4a241df78
In relation to intel/intel-graphics-compiler#204 git-svn-id: file:///srv/repos/svn-community/svn@1044810 9fca08f4-af9d-4005-b8df-a31f2cc04f65
In relation to intel/intel-graphics-compiler#204 git-svn-id: file:///srv/repos/svn-community/svn@1044810 9fca08f4-af9d-4005-b8df-a31f2cc04f65
The versions are in the honister and current master branches of Yocto's openembedded-core, meta-openembedded, meta-clang and meta-intel.
Because in a cross-compiling environment (e.g. Yocto) you have two ways to deal with executables built and run during the build: either use a host-native build variant and use the executables from that (which does not work if the executable relies on type sizes and the host and target are different), or use a Qemu wrapper (e.g. with As far as I know, the qemu-native build Yocto uses for this purpose doesn't limit RAM, it simply allocates from the host system as needed. The target binaries are run just like any regular user-space binary only via the CPU emulator.
According to the above Arch Linux commits, the answer is yes. |
And here's the reasoning from LLVM devs: https://reviews.llvm.org/D105653?id=357321
|
IGC calls Alternatively, the "machine triple" setting: should be |
|
LLVM 14 was also released. |
|
@pszymich sorry for plainly asking, is this planned to be worked on? Do you have any rough estimates? Unfortunately, reverting the offending LLVM 13 change is a no go for Fedora, so compute-runtime support in Fedora depends on this issue. |
|
Just wanted to echo @frantisekz to see if there might be a timeline for resolution on this. It would be great to see this in time for Fedora 36 particularly given that large hardware vendors like Lenovo offer Fedora as a supported OS installed out of the box. |
|
Gentoo also removed LLVM 11 from the distribution this week and LLVM 13 is the current default version. This bug has hit multiple users (including myself). It would be rather important to get this one fixed, as even a plain |
|
@janhenke Is there a problem also with LLVM 12, or does it work as intermediate solution? It's marked as working, but not tested by compute-runtime project as well as LLVM 11: https://github.com/intel/intel-graphics-compiler/projects/2 In my own light testing of my own LLVM 12 build, it worked OK too. |
|
We jumped directly from 11 to 13, so I do not have any test results from 12. As well as some parts of the stack based on LLVM also got removed already. Anyway getting it to work on 13 is rather urgent, as some distributions are following LLVM releases rather closely and keep at most 2-3 releases in their repos (Gentoo is already working towards removing LLVM 12 as said above). |
|
FWIW, LLVM 14 is already in the soon-to-be-released Fedora 36. |
I wonder whether it makes sense for compute-runtime to skip every other LLVM release, and concentrate support only e.g. to odd numbered LLVM releases (11, 13, 15...). Any comments on this from the distro perspective, and from compute-runtime developers? |
|
From Fedora perspective, we are tracking the latest LLVM releases. While it's possible to maintain a compatibility package with the previous version, having the compute-runtime link against older version might cause trouble if the application using it is linked against the latest LLVM libraries (i.e. you get two different LLVM runtimes loaded in the same process). |
Compiling with LLVM13 causes currently segfaults. See intel/intel-graphics-compiler#204 Closes: https://bugs.gentoo.org/837872 Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
Compiling with LLVM13 causes currently segfaults. See intel/intel-graphics-compiler#204 Closes: https://bugs.gentoo.org/837872 Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
In Gentoo, we have an approch of slotted versions, which means, someone can install independently multiple major versions of LLVM and Clang, which all can co-exist. But maintainers will drop older version. We currently have LLVM12 as lowest version, but in future, this one will be dropped.. LLVM11 just got dropped two weeks ago. So LLVM13 support would be very appreciated. |
Compiling with LLVM13 causes currently segfaults. See intel/intel-graphics-compiler#204 Closes: https://bugs.gentoo.org/837872 Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
Compiling with LLVM13 causes currently segfaults. See intel/intel-graphics-compiler#204 Closes: https://bugs.gentoo.org/837872 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org>
It looks like, that this is the case. I tried latest git master and it works for me with LLVM13 now. No segfaults with
As there is a PR for LLVM 14, I wouldn't expect this. |
Backport LLVM 13 fixes from upstream. This fixes the crashes when invoking ocloc after enabling built-ins in compute-runtime. Also see: intel/intel-graphics-compiler#204 Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Today's IGC release CommitDate is from 11th, and those commits are from 17th (of May). So I assume they will be in next release after that. |
|
Fixed in latest commits, closing. |
I have a (not really usable) backtrace from running ocloc via a qemu wrapper when building under Yocto 3.4 with LLVM 13 from meta-clang.
Currently I can only build the latest IGC+compute-runtime via a forked meta-intel Yocto layer if I use
-DNEO_DISABLE_BUILTINS_COMPILATION=1with LLVM 13.The text was updated successfully, but these errors were encountered: