blob: ce7c534978ec3ecb0e33da069087e1b22e850b20 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, let's see. The user is reporting an issue with the QEMU aarch64 emulator where the `sqshrn` instruction isn't emulated correctly. The problem is that specific tests fail in QEMU but pass on real hardware. The tests in question are related to signed saturating shift right narrow operations for 16x1.
First, I need to understand what `sqshrn` does. From what I remember, in ARM architecture, `SQRSHRN` is the Signed Rounding Shift Right Narrow instruction. It shifts the elements of a vector register by a specified number of bits, rounds the result, and then narrows the data type. The 'saturating' part would mean that if the result exceeds the range of the target data type, it's clamped to the maximum or minimum value.
The test cases are expecting certain results when this instruction is executed. On real hardware, it works as expected, but QEMU produces different results. The failures observed are in the expected equality checks where the actual result (`res1` and `res3`) doesn't match the expected 128-bit values.
The key here is that the problem is specific to the emulation of the `sqshrn` instruction in QEMU. The user mentioned that building and running the inline_asm_tests with qemu-aarch64 leads to two failures. The error messages show that the values obtained in QEMU are not matching those from the actual hardware.
Looking at the categories provided: instruction, syscall, runtime. Since the issue is directly related to the incorrect emulation of a specific ARM instruction (`sqshrn`), the problem lies in how QEMU is handling that instruction. There's no mention of system calls or runtime errors outside of instruction execution. Therefore, the correct category should be 'instruction'.
</think>
instruction
|