After implementing Iop_MAdd/Sub for arm64 (bug #426014) we got a report that "the impossible happened": > MSubF64(t15,t21,t22,t23) > vex: the `impossible' happened: > expr_is_guardable: unhandled expr > vex storage: T total 3295105024 bytes allocated > vex storage: P total 0 bytes allocated > > valgrind: the 'impossible' happened: > LibVEX called failure_exit(). And indeed expr_is_guardable doesn't handle Iex_Qop the tag IRExpr_Qop uses. It seems something like the following should work (currently untested): diff --git a/VEX/priv/guest_generic_bb_to_IR.c b/VEX/priv/guest_generic_bb_to_IR.c index 0cee970e4..1e72ddacd 100644 --- a/VEX/priv/guest_generic_bb_to_IR.c +++ b/VEX/priv/guest_generic_bb_to_IR.c @@ -422,6 +422,8 @@ static Bool expr_is_guardable ( const IRExpr* e ) return !primopMightTrap(e->Iex.Binop.op); case Iex_Triop: return !primopMightTrap(e->Iex.Triop.details->op); + case Iex_Qop: + return !primopMightTrap(e->Iex.Qop.details->op); case Iex_ITE: case Iex_CCall: case Iex_Get: I am just surprised this hasn't come up before since other arches (ppc, s390) also implement scalar FMA operations. Some more background in https://bugzilla.redhat.com/show_bug.cgi?id=1844910 (the fedora valgrind package has the arm64 fma patch backported).
commit 42ef710e1928275c98ff72cd82bc5e6b05fe8295 Author: Mark Wielaard <mark@klomp.org> Date: Tue Dec 22 14:51:15 2020 +0100 expr_is_guardable doesn't handle Iex_Qop IRExpr_Qop uses the Iex_Qop tag, which expr_is_guardable didn't handle. https://bugs.kde.org/show_bug.cgi?id=430485