https://bugs.kde.org/show_bug.cgi?id=393036

Peter Maydell <peter.mayd...@linaro.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.mayd...@linaro.org

--- Comment #1 from Peter Maydell <peter.mayd...@linaro.org> ---
Where does the condition "imm5 <= 7" come from? I can't see any justification
for it in the pseudocode for this insn in the v7 or v8 ARM ARM.

My guess is that the incorrect condition check you've hit is the result of
confusion about the pseudocode UNPREDICTABLE condition "d == 13 && (shift_type
!= SRType_LSL || shift_n > 3)", which restricts the permitted shifts if SP is
the destination register. Prior to valgrind commit a70670d3d92f028, the
condition V imposed was "rD != 15 && rN == 13 && imm5 <= 3 && how == 0", which
refused shifts greater than 3 in all cases, not just those with rD == 13. Then
commit a70670d3d92f028 relaxed the imm5 check to <= 5: that correctly accepts a
wider shift range for the rD != 13 case, but incorrectly accepts a wider shift
range if rD == 13, and continues to incorrectly not accept the full up-to-31
shift range for rD != 13.

The patch you attach seems to continue down this route, just bumping the imm5
check up to 7. I think the better approach would be to actually implement the
restrictions the pseudocode requires...

Note also that ARMv8 is less restrictive here than ARMv7 -- v8 removes the
UNPREDICTABLE constraints on R13 operations entirely for this insn. So ideally
V should impose a different condition depending on what architecture version
the CPU it's emulating is.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to