https://bugs.kde.org/show_bug.cgi?id=508661
--- Comment #2 from Carl Love <[email protected]> --- I was able to rerproduce the error. I tracked the failure down to the commit: >From 644d68e9501dd5679194dd5c8e0d3ce24764a1d8 Mon Sep 17 00:00:00 2001 From: Florian Krohm <[email protected]> Date: Wed, 9 Jul 2025 20:15:46 +0000 Subject: [PATCH] Fix operand / result types of Iop_DivU128[E], Iop_ModU128 and their signed counterparts In libvex_ir.h these IROps are described to operate on Ity_I128 operands and produce a like typed result. This contradicts the specification in ir_defs.c (function typeOfprimop) which claims Ity_V128 for operands and result. Above IROps are used exclusively by ppc for the following opcodes: Iop_DivU128 --> vdivuq Vector Divide Unsigned Quadword Iop_DivS128 --> vdivsq Vector Divide Signed Quadword Iop_DivU128E --> vdiveuq Vector Divide Extended Unsigned Quadword Iop_DivS128E --> vdivesq Vector Divide Extended Signed Quadword Iop_ModU128 --> vmoduq Vector Modulo Unsigned Quadword Iop_ModS128 --> vmodsq Vector Modulo Signed Quadword Reading the ISA document, it is clear, that those opcodes perform an integer division / modulo operation. Technically, they work on vector registers, presumably because vector registers are the only resource wide enough to store a quadword. Perhaps that is where the confusion comes from. So Ity_I128 it is. --- VEX/priv/ir_defs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/VEX/priv/ir_defs.c b/VEX/priv/ir_defs.c index 9e7fbf920..ba61758d7 100644 --- a/VEX/priv/ir_defs.c +++ b/VEX/priv/ir_defs.c @@ -3694,10 +3694,12 @@ void typeOfPrimop ( IROp op, case Iop_MulI128by10E: case Iop_MulI128by10ECarry: case Iop_PwExtUSMulQAdd8x16: - case Iop_DivU128: case Iop_DivS128: + BINARY(Ity_V128,Ity_V128, Ity_V128); + + case Iop_DivU128: case Iop_DivS128: case Iop_DivU128E: case Iop_DivS128E: case Iop_ModU128: case Iop_ModS128: - BINARY(Ity_V128,Ity_V128, Ity_V128); + BINARY(Ity_I128,Ity_I128, Ity_I128); case Iop_2xMultU64Add128CarryOut: case Iop_Perm8x16x2: -- 2.50.1 Yes the instructions do integer divisions of 128-bit values that are stored in the V128 registers. The Iops need to operate on the v128 type not on the I128 type due to the register type where they are stored. The underlying PPC support for the various Iops use the corresponding PPC instruction that takes the values from the V128 register and treats the contents as an integer. The patch needs to be reversed to fix the issue. Not sure why the change did not show up in the nightly regression runs. Will look into that. -- You are receiving this mail because: You are watching all bug changes.
