1 files changed, 0 insertions, 29 deletions
diff --git a/results/classifier/semantic-bugs/instruction/826 b/results/classifier/semantic-bugs/instruction/826
deleted file mode 100644
index 3ef3962e..00000000
--- a/results/classifier/semantic-bugs/instruction/826
+++ /dev/null
@@ -1,29 +0,0 @@
-instruction: 0.989
-graphic: 0.822
-device: 0.639
-mistranslation: 0.592
-network: 0.489
-other: 0.438
-assembly: 0.432
-semantic: 0.404
-vnc: 0.261
-socket: 0.178
-boot: 0.132
-KVM: 0.015
-
-AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated
-Description of problem:
-During execution of the following SVE2 instruction:
-`ldnt1sb {z6.d}, p3/z, [z14.d, x9]`
-with the following register state:
-```
-(gdb) p $p3
-$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0}
-(gdb) p $z14.d.u
-$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45}
-(gdb) p $x9
-$3 = 0x0
-```
-QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load.
-Additional information:
-A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different.