https://bugs.kde.org/show_bug.cgi?id=418004
--- Comment #1 from Carl Love <c...@us.ibm.com> --- Created attachment 126876 --> https://bugs.kde.org/attachment.cgi?id=126876&action=edit Additional PPC 64 grail fixes The issue that is causing regression errors on PPC64 has to do with the grail changes as mentioned in some private emails. Specifically the commit in question is: commit 076a79a48e251067758e1e9d8e50681450ed3889 Author: Julian Seward <jsew...@acm.org> Date: Wed Nov 27 08:52:45 2019 +0100 'grail' fixes for ppc32 and ppc64: * do_minimal_initial_iropt_BB: for ppc64, flatten rather than assert flatness. (Kludge. Sigh.) etc. The patch adds the following code in ir_opt.c // FIXME2 The TOC-redirect-hacks generators in m_translate.c -- gen_PUSH() // and gen_PO() -- don't generate flat IR, and so cause this assertion // to fail. For the time being, hack around this by flattening, // rather than asserting for flatness, on the afflicted platforms. // This is a kludge, yes. if (guest_arch == VexArchPPC64) { bb0 = flatten_BB(bb0); // Kludge! } else { vassert(isFlatIRSB(bb0)); // How it Really Should Be (tm). } The issue comes from the new expressions generated by flatten_BB(bb0). As mentioned in previous private emails, the flatten_BB() generates V128 expressions for Iex_ITE which is not supported. The following patch adds the needed support for Iex_ITE for V128 expressions. I kinda get what the Iex_ITE needs to do but don't claim to completely understand it all or why the kludge calls flatten_BB() only for the PPC64 architecture. -- You are receiving this mail because: You are watching all bug changes.
