add manually reviewed semantic bugs

author: Christian Krinitsin <mail@krinitsin.com> 2025-06-12 09:56:59 +0200
committer: Christian Krinitsin <mail@krinitsin.com> 2025-06-12 09:56:59 +0200
commit: b89a938452613061c0f1f23e710281cf5c83cb29 (patch)
tree: d5faecfd167e088848cad894f8dc9cfef3352e3b /results/classifier
parent: 7b681b9f9eedaad2f081ae11a32f459f5a1312ff (diff)
download: qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.tar.gz
qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.zip
94 files changed, 6382 insertions, 0 deletions
diff --git a/results/classifier/semantic-bugs/assembly/1612 b/results/classifier/semantic-bugs/assembly/1612
new file mode 100644
index 000000000..aa2f4e529
--- /dev/null
+++ b/results/classifier/semantic-bugs/assembly/1612
@@ -0,0 +1,64 @@
+assembly: 0.776
+instruction: 0.670
+graphic: 0.648
+semantic: 0.641
+device: 0.599
+other: 0.486
+network: 0.456
+socket: 0.453
+boot: 0.407
+vnc: 0.367
+mistranslation: 0.229
+KVM: 0.225
+
+SVE first-faulting gather loads return incorrect data
+Description of problem:
+The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master.
+Steps to reproduce:
+1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`.
+
+asmtest.s
+```
+    .type asmtest, @function
+    .balign 16
+    .global asmtest
+asmtest:
+    setffr
+    ptrue   p0.d
+    index   z1.d, #0, #1
+    ldff1d  z1.d, p0/z, [x0, z1.d, LSL #3]
+    rdffr   p1.b
+    st1d    {z1.d}, p0, [x1]
+    str     p1, [x2]
+    ret
+```
+
+This harness for convenience intialises some data and checks the element at index 1, which should be 1.
+
+test.c
+```
+#include <arm_sve.h>
+#include <stdio.h>
+
+void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr);
+
+int main() {
+    const int64_t data[] = {42,  1,  2,  3,  4,  5,  6,  7,  8,  9,  10,
+                          11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
+                          22, 23, 24, 25, 26, 27, 28, 29, 30, 31};
+    svint64_t loaded;
+    svbool_t ffr;
+
+    asmtest(data, &loaded, &ffr);
+
+    // Check value of element at index 1
+    svuint64_t lanes = svindex_u64(0, 1);
+    svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1);
+    printf("%ld\n", svaddv_s64(lane, loaded));
+}
+```
+
+2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest```
+3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42.
+Additional information:
+The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load.
diff --git a/results/classifier/semantic-bugs/assembly/1620 b/results/classifier/semantic-bugs/assembly/1620
new file mode 100644
index 000000000..ecfad33cc
--- /dev/null
+++ b/results/classifier/semantic-bugs/assembly/1620
@@ -0,0 +1,107 @@
+assembly: 0.775
+other: 0.747
+device: 0.720
+KVM: 0.715
+instruction: 0.707
+mistranslation: 0.702
+semantic: 0.688
+graphic: 0.672
+vnc: 0.639
+socket: 0.616
+boot: 0.561
+network: 0.554
+
+SME FMOPA outer product instruction gives incorrect result
+Description of problem:
+The SME outer product instructions operate on tiles of elements. In the
+below example we are performing an outer product of a vector of 1.0
+by itself. This naturally should produce a matrix filled with 1.0
+values, however if we read the values of the tile and printf them we
+instead observe 0.0 values.
+
+Without digging into the underlying QEMU code this appears to be a bug
+in how elements are set based on the tile number, since the same code
+using za0.s rather than za1.s correctly reports all 1.0 values as output
+as expected.
+
+main.c
+```
+#include <stdio.h>
+
+void foo(float *dst);
+
+int main() {
+  float dst[16];
+  foo(dst);
+
+  // This should print:
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  // >>> 1.000000  1.000000  1.000000  1.000000
+  for (int i=0; i<4; ++i) {
+    printf(">>> ");
+    for (int j=0; j<4; ++j) {
+      printf("%lf  ", (double)dst[i * 4 + j]);
+    }
+    printf("\n");
+  }
+}
+```
+
+foo.S
+```
+.global foo
+foo:
+  stp x29, x30, [sp, -80]!
+  mov x29, sp
+  stp d8, d9, [sp, 16]
+  stp d10, d11, [sp, 32]
+  stp d12, d13, [sp, 48]
+  stp d14, d15, [sp, 64]
+
+  smstart
+
+  ptrue p0.s, vl4
+  fmov z0.s, #1.0
+
+  // An outer product of a vector of 1.0 by itself should be a matrix of 1.0.
+  // Note that we are using tile 1 here (za1.s) rather than tile 0.
+  zero {za}
+  fmopa za1.s, p0/m, p0/m, z0.s, z0.s
+
+  // Read the first 4x4 sub-matrix of elements from tile 1:
+  // Note that za1h should be interchangable here.
+  mov w12, #0
+  mova z0.s, p0/m, za1v.s[w12, #0]
+  mova z1.s, p0/m, za1v.s[w12, #1]
+  mova z2.s, p0/m, za1v.s[w12, #2]
+  mova z3.s, p0/m, za1v.s[w12, #3]
+
+  // And store them to the input pointer (dst in the C code):
+  st1w {z0.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z1.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z2.s}, p0, [x0]
+  add x0, x0, #16
+  st1w {z3.s}, p0, [x0]
+
+  smstop
+
+  ldp d8, d9, [sp, 16]
+  ldp d10, d11, [sp, 32]
+  ldp d12, d13, [sp, 48]
+  ldp d14, d15, [sp, 64]
+  ldp x29, x30, [sp], 80
+  ret
+```
+Steps to reproduce:
+```
+$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static
+$ ~/qemu/build/qemu-aarch64 ./a.out
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+>>> 0.000000  0.000000  0.000000  0.000000
+```
diff --git a/results/classifier/semantic-bugs/assembly/1649 b/results/classifier/semantic-bugs/assembly/1649
new file mode 100644
index 000000000..7d78cca98
--- /dev/null
+++ b/results/classifier/semantic-bugs/assembly/1649
@@ -0,0 +1,30 @@
+assembly: 0.984
+instruction: 0.900
+graphic: 0.900
+device: 0.747
+semantic: 0.642
+vnc: 0.610
+network: 0.592
+socket: 0.542
+mistranslation: 0.500
+boot: 0.379
+KVM: 0.352
+other: 0.209
+
+"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register
+Description of problem:
+slli a0, a0, 8 (1)
+    la a0, mtimvec (2)
+    csrw mtvec, a0 (3)
+    mtimvec:       (4)
+
+For the above assembly snippet, the mtvec could be successfully set to the value of a0 
+without the presence of the line (1) or with the shift amount being zero. However, 
+the mtvec can never be set successfully with the presence of line (1).
+Steps to reproduce:
+1. Create a test.s file and put these 4 lines of assembly into the file
+2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S"
+3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0.
+4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/assembly/904 b/results/classifier/semantic-bugs/assembly/904
new file mode 100644
index 000000000..4946b8146
--- /dev/null
+++ b/results/classifier/semantic-bugs/assembly/904
@@ -0,0 +1,29 @@
+assembly: 0.991
+instruction: 0.939
+graphic: 0.875
+device: 0.846
+semantic: 0.662
+network: 0.599
+mistranslation: 0.507
+vnc: 0.485
+boot: 0.425
+socket: 0.381
+KVM: 0.219
+other: 0.191
+
+RISC-V: Cannot set SEIP bit of mip csr register in M mode
+Description of problem:
+
+Steps to reproduce:
+1.   run assembly instructions **in M mode**: 
+```
+not t0, x0    // set t0 to 0b11..11
+csrs mip, t0  // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values)
+csrr t1, mip  // read value from mip to t1
+```
+2.   GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set.
+3.   According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`.
+4.   According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`.
+5.   However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/boot/1748296 b/results/classifier/semantic-bugs/boot/1748296
new file mode 100644
index 000000000..cab7dadc5
--- /dev/null
+++ b/results/classifier/semantic-bugs/boot/1748296
@@ -0,0 +1,95 @@
+boot: 0.673
+device: 0.671
+semantic: 0.667
+other: 0.644
+instruction: 0.641
+mistranslation: 0.640
+network: 0.584
+graphic: 0.581
+assembly: 0.566
+KVM: 0.560
+socket: 0.552
+vnc: 0.462
+
+TCG throws Invalid Opcode when executing x86 BMI shlx instruction
+
+I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception.
+
+The code executes correctly and passes the test under KVM.
+
+I have created a complete repro here: https://github.com/doug65536/qemu-bmibug
+
+The makefile has the following utility targets:
+
+debug-kvm: Build and run the VM using KVM and wait for gdbstub attach
+
+run: Run the test case with TCG, make fails if the test fails. (It will fail)
+
+run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed)
+
+debug: Build and run the VM with TCG and wait for GDB attach
+
+attach-gdb: Run GDB and attach to KVM gdbstub
+
+The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM.
+
+You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails.
+
+I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX.
+
+I hit this today on QEMU head. The problem appears to crop up when:
+
+  1. Decoding a VEX instruction (see [1]) that uses the 0x66 mandatory
+     prefix; and
+
+  2. The OSFXSR bit in CR4 is clear (that is, SSE is disabled)
+
+This means that x86_64 instructions such as:
+
+     c4 e2 f9 f7 c0                shlxq   %rax, %rax, %rax
+
+fail. Similar instructions the use a different mandatory prefix
+(such as `shrxq`, which uses prefix 0xf2) work fine.
+
+Most operating systems presumably set the OSFXSR bit fairly early on, which I
+guess is why this problem isn't likely to be seen except in low-level or early
+boot code.
+
+The culprit appears to be the block of code in `gen_sse` [2]:
+
+    if (is_xmm
+        && !(s->flags & HF_OSFXSR_MASK)
+        && ((b != 0x38 && b != 0x3a) || (s->prefix & PREFIX_DATA))) {
+        goto unknown_op;
+    }
+
+Removing the check `... || (s->prefix & DATA_DATA)` causes QEMU to correctly
+translate the instruction, and allows doug16k's test above to pass.
+
+I must confess, I'm not clear what this clause was testing for. My best guess
+is that early code (e.g. 4242b1bd8ac) required it to avoid accessing invalid
+opcode tables, but we seem to be handling that more gracefully today (e.g.
+[3]), so I suspect it is no longer needed.
+
+[1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#VEX.2FXOP_opcodes
+[2]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3078
+[3]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3696-L3700
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+Ah, never mind, posted the text before seeing that it still affects people in 2021 ... so I'm not changing this bug to "Incomplete". Sorry for the noise.
+
+Fix has been included here:
+https://gitlab.com/qemu-project/qemu/-/commit/51909241d26fe6fe18a
+
diff --git a/results/classifier/semantic-bugs/graphic/1641637 b/results/classifier/semantic-bugs/graphic/1641637
new file mode 100644
index 000000000..dff815184
--- /dev/null
+++ b/results/classifier/semantic-bugs/graphic/1641637
@@ -0,0 +1,743 @@
+graphic: 0.957
+instruction: 0.942
+semantic: 0.931
+mistranslation: 0.910
+other: 0.901
+assembly: 0.881
+device: 0.878
+socket: 0.874
+KVM: 0.857
+boot: 0.846
+network: 0.842
+vnc: 0.842
+
+incorrect illegal SSE3 instructions reporting on x86_64
+
+Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following:
+
+pabsb %mm0, %mm1
+pabsb %xmm0, %xmm1
+pabsd %mm0, %mm1
+pabsd %xmm0, %xmm1
+pabsw %mm0, %mm1
+pabsw %xmm0, %xmm1
+phaddd %mm0, %mm1
+phaddd %xmm0, %xmm1
+phaddsw %mm0, %mm1
+phaddsw %xmm0, %xmm1
+phaddw %mm0, %mm1
+phaddw %xmm0, %xmm1
+phsubd %mm0, %mm1
+phsubd %xmm0, %xmm1
+phsubsw %mm0, %mm1
+phsubsw %xmm0, %xmm1
+phsubw %mm0, %mm1
+phsubw %xmm0, %xmm1
+pmaddubsw %mm0, %mm1
+pmaddubsw %xmm0, %xmm1
+pmulhrsw %mm0, %mm1
+pmulhrsw %xmm0, %xmm1
+psignb %mm0, %mm1
+psignb %xmm0, %xmm1
+psignd %mm0, %mm1
+psignd %xmm0, %xmm1
+psignw %mm0, %mm1
+psignw %xmm0, %xmm1
+
+The following is the proof of code 
+
+/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("pabsb %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 1.c **********/
+
+
+/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("pabsb %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 2.c **********/
+
+
+/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("pabsd %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 3.c **********/
+
+
+/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("pabsd %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 4.c **********/
+
+
+/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("pabsw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 5.c **********/
+
+
+/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("pabsw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 6.c **********/
+
+
+/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phaddd %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 7.c **********/
+
+
+/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phaddd %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 8.c **********/
+
+
+/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phaddsw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 9.c **********/
+
+
+/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phaddsw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 10.c **********/
+
+
+/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phaddw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 11.c **********/
+
+
+/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phaddw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 12.c **********/
+
+
+/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phsubd %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 13.c **********/
+
+
+/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phsubd %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 14.c **********/
+
+
+/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phsubsw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 15.c **********/
+
+
+/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phsubsw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 16.c **********/
+
+
+/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("phsubw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 17.c **********/
+
+
+/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("phsubw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 18.c **********/
+
+
+/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char i2[0x10];
+unsigned char i3[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));;
+    asm("pmaddubsw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 19.c **********/
+
+
+/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char i2[0x10];
+unsigned char i3[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));;
+    asm("pmaddubsw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 20.c **********/
+
+
+/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("pmulhrsw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 21.c **********/
+
+
+/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("pmulhrsw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 22.c **********/
+
+
+/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("psignb %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 23.c **********/
+
+
+/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("psignb %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 24.c **********/
+
+
+/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("psignd %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 25.c **********/
+
+
+/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("psignd %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 26.c **********/
+
+
+/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));;
+    asm("psignw %mm0, %mm1");
+    asm("mov %0, %%rdx\n"
+        "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 27.c **********/
+
+
+/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char i1[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));;
+    asm("mov %0, %%rdx\n"
+        "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));;
+    asm("psignw %xmm0, %xmm1");
+    asm("mov %0, %%rdx\n"
+        "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+
+/********** End of bug 28.c **********/
+
+For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, 
+
+$ gcc 28.c -o 28
+$ qemu-x86_64 ./28
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+$ ./28
+00000000000000000000000000000000
+
+Some information about the system:
+
+$ qemu-x86_64 --version
+qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
+$ uname -a
+Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
+$ gcc --version
+gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
+Copyright (C) 2013 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Thanks!
+
+Hi Jie,
+
+I can reproduce this by single-stepping through the bug1 testing code using gdb, and SIGILL was encountered when executing the pabsb SSE3 instruction. Maybe it was due to QEMU's translator, I'll look further into it. 
+
+Hi Jie, 
+
+Seems that the problem was caused by not specifying the cpu model when running QEMU.
+when running 
+qemu-x86_64 ./28
+QEMU would recognize the cpu model as "qemu64", which act like a cpu doesn't support advanced instruction sets like SSSE3. To workaround, you can run
+qemu-x86_86 -cpu core2duo ./28
+The cpu specifications could be found at target-i386/cpu.c. 
+
+I haven't tested through all the cases yet, but I'm almost sure that was the problem, for all your test cases used SSSE3 instructions or something alike. 
+Please let me know if there are some more exceptions, thanks!
+
diff --git a/results/classifier/semantic-bugs/graphic/1722 b/results/classifier/semantic-bugs/graphic/1722
new file mode 100644
index 000000000..4dcbfc5fe
--- /dev/null
+++ b/results/classifier/semantic-bugs/graphic/1722
@@ -0,0 +1,100 @@
+graphic: 0.963
+semantic: 0.957
+device: 0.956
+mistranslation: 0.954
+other: 0.948
+vnc: 0.944
+instruction: 0.943
+assembly: 0.934
+network: 0.909
+socket: 0.896
+boot: 0.813
+KVM: 0.808
+
+qemu-mipsn32: Illegal Instruction at `exts` instruction
+Description of problem:
+Run with the command above, I got this error:
+
+```
+qemu-mipsn32 run
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)
+```
+
+I then tried to debug the program with qemu option `-g 1234` and know that 
+
+```
+$ gdb-multiarch run
+...
+
+pwndbg> target remote 0:1234
+...
+
+pwndbg> c
+Continuing.
+
+Program received signal SIGILL, Illegal instruction.
+0x3f7d2434 in ?? () from /lib32/ld.so.1
+warning: GDB can't find the start of the function at 0x3f7d2434.
+x/10i
+
+pwndbg> x/10i $pc
+=> 0x3f7d2434:	0x7047f03a
+   0x3f7d2438:	lui	a3,0x7000
+   0x3f7d243c:	ori	a3,a3,0x5e
+   0x3f7d2440:	b	0x3f7d241c
+   0x3f7d2444:	subu	v0,a3,v0
+   0x3f7d2448:	sltiu	a7,a3,-3
+   0x3f7d244c:	bnezl	a7,0x3f7d246c
+   0x3f7d2450:	subu	a3,a4,v0
+   0x3f7d2454:	addiu	a3,a3,1
+   0x3f7d2458:	li	v0,-4
+```
+
+So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below:
+
+```
+$ file /lib32/ld.so.1
+/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped
+
+$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less
+    ...
+    4434:       7047f03a        exts    a3,v0,0x0,0x1e
+    4438:       3c077000        lui     a3,0x7000
+    443c:       34e7005e        ori     a3,a3,0x5e
+    4440:       1000fff6        b       441c <GLIBC_2.0@@GLIBC_2.0+0x441c>
+    4444:       00e21023        subu    v0,a3,v0
+    4448:       2cebfffd        sltiu   a7,a3,-3
+    444c:       55600007        bnezl   a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c>
+    4450:       01023823        subu    a3,a4,v0
+    4454:       24e70001        addiu   a3,a3,1
+    4458:       2402fffc        li      v0,-4
+```
+Steps to reproduce:
+1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html)
+2. Write this c code to file `run.c`:
+
+```c
+#include <stdio.h>
+
+int main(){
+	puts("hello world");
+	while (1);
+}
+```
+
+3. Compile file run.c with downloaded toolchain:
+
+```
+mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run
+```
+
+> Step 1, 2 and 3 can be skip if you download the attached `run` file.
+
+4. Download the attached ld
+5. Make new dir at `/lib32` and move the file ld to `/lib32`
+6. Run command `qemu-mipsn32 run`
+Additional information:
+[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so)
+
+[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run)
diff --git a/results/classifier/semantic-bugs/graphic/2595 b/results/classifier/semantic-bugs/graphic/2595
new file mode 100644
index 000000000..e0e1afbe0
--- /dev/null
+++ b/results/classifier/semantic-bugs/graphic/2595
@@ -0,0 +1,148 @@
+graphic: 0.959
+other: 0.957
+semantic: 0.951
+mistranslation: 0.934
+device: 0.919
+assembly: 0.915
+socket: 0.901
+boot: 0.896
+instruction: 0.895
+vnc: 0.886
+network: 0.861
+KVM: 0.850
+
+Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64
+Description of problem:
+The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE.
+
+I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect.
+Steps to reproduce:
+1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets.
+2. Compile the following program with these compiler arguments
+
+   ```
+   arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane
+   ```
+
+   ```c
+   #include <stdio.h>
+   #include <arm_sve.h>
+   
+   int64_t a[32] = { 0 };
+   int16_t b[128];
+   int16_t c[128];
+   int64_t r[32];
+   int64_t expected_r[32];
+   
+   #define IMM 0
+   
+   int main(void)
+   {
+       for (size_t i = 0; i < 128; i++) {
+           b[i] = 1;
+           c[i] = i / 4;
+       }
+   
+       svint64_t av = svld1(svptrue_b64(), a);
+       svint16_t bv = svld1(svptrue_b16(), b);
+       svint16_t cv = svld1(svptrue_b16(), c);
+   
+       svint64_t result = svdot_lane_s64(av, bv, cv, IMM);
+   
+       svst1(svptrue_b64(), r, result);
+   
+       for (size_t i = 0; i < svcntd(); i++) {
+           expected_r[i] = 
+               (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] +
+               (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] +
+               (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] +
+               (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] +
+               a[i];
+       }
+       
+       printf("%12s", "r: ");
+       for (size_t i = 0; i < svcntd(); i++) {
+           printf("%4ld", r[i]);
+       }
+       printf("\n");
+       printf("%12s", "expected_r: ");
+       for (size_t i = 0; i < svcntd(); i++) {
+           printf("%4ld", expected_r[i]);
+       }
+       printf("\n\t\t");
+       for (size_t i = 0; i < svcntd(); i++) {
+           if (r[i] != expected_r[i]) {
+               printf("%4c", '^');
+           } else {
+               printf("%4c", ' ');
+           }
+       }
+       printf("\n");
+       printf("idx:\t\t");
+       for (size_t i = 0; i < svcntd(); i++) {
+           if (r[i] != expected_r[i]) {
+               printf("%4d", i);
+           } else {
+               printf("%4c", ' ');
+           }
+       }
+       printf("\n");
+   
+       return 0;
+   }
+   ```
+3. Execute it with the following commands:
+
+   ```
+   qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane
+   ```
+
+   Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect.
+
+   `sve-default-vector-length=16`
+
+   ```
+            r:    0   0
+   expected_r:    0   0
+                           
+   idx:                
+   ```
+
+   `sve-default-vector-length=32`
+
+   ```
+            r:    0   0   8   8
+   expected_r:    0   0   8   8
+                                   
+   idx:                        
+   ```
+
+   `sve-default-vector-length=64`
+
+   ```
+            r:    0   0   8   8   8   8  24  24
+   expected_r:    0   0   8   8  16  16  24  24
+                                      ^   ^        
+   idx:                               4   5         
+   ```
+
+   `sve-default-vector-length=128`
+
+   ```
+            r:    0   0   8   8   8   8  24  24  24  24  40  40  40  40  56  56
+   expected_r:    0   0   8   8  16  16  24  24  32  32  40  40  48  48  56  56
+                                      ^   ^           ^   ^           ^   ^        
+   idx:                               4   5           8   9          12  13       
+   ```
+
+   `sve-default-vector-length=256`
+
+   ```
+            r:    0   0   8   8   8   8  24  24  24  24  40  40  40  40  56  56  56  56  72  72  72  72  88  88  88  88 104 104 104 104 120 120
+   expected_r:    0   0   8   8  16  16  24  24  32  32  40  40  48  48  56  56  64  64  72  72  80  80  88  88  96  96 104 104 112 112 120 120
+                                      ^   ^           ^   ^           ^   ^           ^   ^           ^   ^           ^   ^           ^   ^        
+   idx:                               4   5           8   9          12  13          16  17          20  21          24  25          28  29     
+   ```
+4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D).
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/graphic/2672 b/results/classifier/semantic-bugs/graphic/2672
new file mode 100644
index 000000000..3a1f3f9a5
--- /dev/null
+++ b/results/classifier/semantic-bugs/graphic/2672
@@ -0,0 +1,33 @@
+graphic: 0.901
+instruction: 0.868
+device: 0.714
+vnc: 0.423
+socket: 0.247
+boot: 0.240
+mistranslation: 0.222
+semantic: 0.216
+network: 0.205
+assembly: 0.203
+other: 0.148
+KVM: 0.040
+
+Skipping a jal instruction in riscv64 baremetal emulation
+Description of problem:
+The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception:
+
+```
+0x80006070:  00200513          addi                    a0,zero,2
+0x80006074:  89cff0ef          jal                     ra,-3940                # 0x80005110
+
+----------------
+IN: _Z15int_switch_modehh
+0x80006078:  0000              illegal                 
+
+----------------
+IN: mtvec_table
+0x8000e600:  64d0406f          j                       20044                   # 0x8001344c
+```
+Steps to reproduce:
+1. Execute the same binary with QEMU.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/graphic/904308 b/results/classifier/semantic-bugs/graphic/904308
new file mode 100644
index 000000000..a32657642
--- /dev/null
+++ b/results/classifier/semantic-bugs/graphic/904308
@@ -0,0 +1,201 @@
+graphic: 0.975
+other: 0.967
+assembly: 0.959
+device: 0.954
+semantic: 0.949
+instruction: 0.941
+boot: 0.934
+socket: 0.929
+network: 0.906
+vnc: 0.879
+mistranslation: 0.833
+KVM: 0.820
+
+x86: BT/BTS/BTR/BTC: ZF flag is unaffected
+
+Hello!
+
+Bug was found in qemu.git.
+See target-i386/translate.c:
+
+    case 0x1ba: /* bt/bts/btr/btc Gv, im */
+        ot = dflag + OT_WORD;
+        modrm = ldub_code(s->pc++);
+        op = (modrm >> 3) & 7;
+        mod = (modrm >> 6) & 3;
+        rm = (modrm & 7) | REX_B(s);
+        if (mod != 3) {
+            s->rip_offset = 1;
+            gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
+            gen_op_ld_T0_A0(ot + s->mem_index);
+        } else {
+            gen_op_mov_TN_reg(ot, 0, rm);
+        }
+        /* load shift */
+        val = ldub_code(s->pc++);
+        gen_op_movl_T1_im(val);
+        if (op < 4)
+            goto illegal_op;
+        op -= 4;
+        goto bt_op;
+    case 0x1a3: /* bt Gv, Ev */
+        op = 0;
+        goto do_btx;
+    case 0x1ab: /* bts */
+        op = 1;
+        goto do_btx;
+    case 0x1b3: /* btr */
+        op = 2;
+        goto do_btx;
+    case 0x1bb: /* btc */
+        op = 3;
+    do_btx:
+        ot = dflag + OT_WORD;
+        modrm = ldub_code(s->pc++);
+        reg = ((modrm >> 3) & 7) | rex_r;
+        mod = (modrm >> 6) & 3;
+        rm = (modrm & 7) | REX_B(s);
+        gen_op_mov_TN_reg(OT_LONG, 1, reg);
+        if (mod != 3) {
+            gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
+            /* specific case: we need to add a displacement */
+            gen_exts(ot, cpu_T[1]);
+            tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot);
+            tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot);
+            tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0);
+            gen_op_ld_T0_A0(ot + s->mem_index);
+        } else {
+            gen_op_mov_TN_reg(ot, 0, rm);
+        }
+    bt_op:
+        tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1);
+        switch(op) {
+        case 0:
+            tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
+            tcg_gen_movi_tl(cpu_cc_dst, 0);                               <<<<<<<<<<<<<<<<<<<<<< always set zf
+            break;
+        case 1:
+            tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+            tcg_gen_movi_tl(cpu_tmp0, 1);
+            tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
+            tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
+            break;
+        case 2:
+            tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+            tcg_gen_movi_tl(cpu_tmp0, 1);
+            tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
+            tcg_gen_not_tl(cpu_tmp0, cpu_tmp0);
+            tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
+            break;
+        default:
+        case 3:
+            tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
+            tcg_gen_movi_tl(cpu_tmp0, 1);
+            tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
+            tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
+            break;
+        }
+        s->cc_op = CC_OP_SARB + ot;
+        if (op != 0) {
+            if (mod != 3)
+                gen_op_st_T0_A0(ot + s->mem_index);
+            else
+                gen_op_mov_reg_T0(ot, rm);
+            tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4);
+            tcg_gen_movi_tl(cpu_cc_dst, 0);                           <<<<<<<<<<<<<<<<<<<<<< always set zf
+        }
+        break;
+
+always set zf...
+
+There is fixed patch.
+
+
+
+It would be helpful if you could submit patches in line with the guidance documented on the wiki:
+http://wiki.qemu.org/Contribute/SubmitAPatch
+
+In particular, patches should be sent to the mailing list in the right format, and we cannot apply any patch without a signed-off-by line.
+
+Thanks.
+
+
+On 12/14/2011 06:08 PM, malc wrote:
+> On Wed, 14 Dec 2011, Daniil Troshkov wrote:
+>
+> > Public bug reported:
+> > 
+> > Hello!
+> > 
+> > Bug was found in qemu.git.
+> > See target-i386/translate.c:
+> > 
+>
+> [..snip..]
+>
+> Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so,
+> question is: why do you think QEMU is wrong here?
+
+The Intel documentation states that ZF is unaffected.
+
+-- 
+error compiling committee.c: too many arguments to function
+
+
+
+On 12/14/2011 06:22 PM, malc wrote:
+> On Wed, 14 Dec 2011, Avi Kivity wrote:
+>
+> > On 12/14/2011 06:08 PM, malc wrote:
+> > > On Wed, 14 Dec 2011, Daniil Troshkov wrote:
+> > >
+> > > > Public bug reported:
+> > > > 
+> > > > Hello!
+> > > > 
+> > > > Bug was found in qemu.git.
+> > > > See target-i386/translate.c:
+> > > > 
+> > >
+> > > [..snip..]
+> > >
+> > > Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so,
+> > > question is: why do you think QEMU is wrong here?
+> > 
+> > The Intel documentation states that ZF is unaffected.
+> > 
+>
+> Right, i was blind, anyways, AMD disagrees. 
+>
+
+Best to be conservative here.
+
+-- 
+error compiling committee.c: too many arguments to function
+
+
+
+>Best to be conservative here.
+What is it means?
+
+On 12/14/2011 06:33 PM, malc wrote:
+> > 
+> > Best to be conservative here.
+> > 
+>
+> Point being, any code that relies on it being in any particular state is
+> broken (potentially, on AMD chips)
+
+Yes of course, but not all software is written to be portable.  Probably
+the only thing that will break here is a vendor test suite, but even so,
+if we can comply to the spec, we should.
+
+-- 
+error compiling committee.c: too many arguments to function
+
+
+
+Looking at the previous comments ... is there anything left to do here? Or can we close this bug nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1057 b/results/classifier/semantic-bugs/instruction/1057
new file mode 100644
index 000000000..5815e3deb
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1057
@@ -0,0 +1,36 @@
+instruction: 0.938
+semantic: 0.521
+device: 0.491
+other: 0.379
+assembly: 0.282
+graphic: 0.233
+network: 0.207
+mistranslation: 0.133
+socket: 0.065
+KVM: 0.060
+vnc: 0.056
+boot: 0.050
+
+AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions
+Description of problem:
+I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
+`0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4`
+
+notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.
+
+Here is the relevant part of the manual:
+
+```
+For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
+• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).
+```
+
+However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.
+
+Another example of instruction: `0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!`
+Steps to reproduce:
+1. Run some hypervisor in EL2
+2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
+3. Observe the value of ESR_EL2 on data abort
+
+Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch.
diff --git a/results/classifier/semantic-bugs/instruction/1062 b/results/classifier/semantic-bugs/instruction/1062
new file mode 100644
index 000000000..67d2da1cb
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1062
@@ -0,0 +1,29 @@
+instruction: 0.925
+graphic: 0.906
+assembly: 0.851
+device: 0.826
+mistranslation: 0.798
+socket: 0.727
+network: 0.651
+semantic: 0.646
+vnc: 0.606
+other: 0.562
+boot: 0.478
+KVM: 0.082
+
+AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32
+Description of problem:
+In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support.
+
+This would break this EL3 code, which should run on cpu reset to attempt to return to EL1:
+```asm
+mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked
+mov SPSR_EL3, x1
+adr x1, 1f
+msr ELR_EL3, x1
+eret
+1:
+; something something
+```
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/instruction/1079080 b/results/classifier/semantic-bugs/instruction/1079080
new file mode 100644
index 000000000..c3723248d
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1079080
@@ -0,0 +1,43 @@
+instruction: 0.967
+graphic: 0.903
+device: 0.901
+semantic: 0.833
+network: 0.755
+socket: 0.707
+vnc: 0.648
+boot: 0.648
+other: 0.637
+mistranslation: 0.619
+assembly: 0.187
+KVM: 0.100
+
+ARM instruction "srs" wrong behaviour
+
+Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R :
+"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode"
+
+Problem:
+When executing this instruction, the register stored is CPSR instead of SPSR.
+
+Context:
+Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line:
+qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic
+
+It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009.
+
+Can you make the test case dtb and image available? That would help in testing...
+
+
+
+
+
+
+Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/
+
+If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message...
+
+
+You are welcome. 
+Credit info you need: Cesson Vincent <email address hidden>
+Thank you for fixing it!
+
diff --git a/results/classifier/semantic-bugs/instruction/1092 b/results/classifier/semantic-bugs/instruction/1092
new file mode 100644
index 000000000..544940be7
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1092
@@ -0,0 +1,27 @@
+instruction: 0.963
+mistranslation: 0.914
+device: 0.801
+graphic: 0.636
+semantic: 0.492
+network: 0.383
+other: 0.340
+vnc: 0.339
+boot: 0.313
+socket: 0.296
+assembly: 0.171
+KVM: 0.030
+
+PPC: `sraw` instructions does not set `ca` and `ca32` flags.
+Description of problem:
+The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to
+[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should.
+Additional information:
+This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`).
+
+**sraw**
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914
+
+**srawi**
+
+https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924
diff --git a/results/classifier/semantic-bugs/instruction/1095857 b/results/classifier/semantic-bugs/instruction/1095857
new file mode 100644
index 000000000..a74648b9b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1095857
@@ -0,0 +1,29 @@
+instruction: 0.914
+mistranslation: 0.764
+graphic: 0.736
+device: 0.679
+other: 0.555
+semantic: 0.442
+network: 0.323
+assembly: 0.286
+socket: 0.242
+boot: 0.214
+vnc: 0.198
+KVM: 0.114
+
+incorrect handling of [r32] address (long mode)
+
+while executing in Long Mode (x86-64) instructions such as
+
+mov eax,[r15d]
+
+end up executing as
+
+mov eax,[r15]
+
+according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions.
+
+You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1156 b/results/classifier/semantic-bugs/instruction/1156
new file mode 100644
index 000000000..83908c6d9
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1156
@@ -0,0 +1,14 @@
+instruction: 0.874
+mistranslation: 0.834
+device: 0.815
+assembly: 0.455
+graphic: 0.452
+semantic: 0.202
+boot: 0.139
+network: 0.079
+other: 0.068
+socket: 0.017
+KVM: 0.017
+vnc: 0.007
+
+Incorrect implementation of vmsumudm instruction
diff --git a/results/classifier/semantic-bugs/instruction/1204 b/results/classifier/semantic-bugs/instruction/1204
new file mode 100644
index 000000000..e47ce874a
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1204
@@ -0,0 +1,42 @@
+instruction: 0.457
+device: 0.406
+graphic: 0.397
+semantic: 0.357
+network: 0.356
+socket: 0.345
+assembly: 0.330
+vnc: 0.306
+mistranslation: 0.284
+other: 0.165
+boot: 0.147
+KVM: 0.125
+
+AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0
+Description of problem:
+As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119).
+Memory regions marked as Device do not support unaligned access.
+Steps to reproduce:
+Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault)
+```
+.balign 8
+.global first_variable
+first_variable:
+      .word 0x1
+.balign 4
+.global second_variable
+second_variable:
+      .word 0x2
+
+no_mmu_sctlr: .dword 0x0000000030C51834
+
+.globl reproducer
+reproducer:
+      ldr  x1, no_mmu_sctlr // A=0,M=0
+      msr  sctlr_el3, x1
+      dsb  sy
+      isb
+
+      ldr  x0, =first_variable
+      ldr  x1, [x0, #0] // Aligned - Success
+      ldr  x1, [x0, #4] // Unaligned - Success??? (Should be failure)
+```
diff --git a/results/classifier/semantic-bugs/instruction/1245543 b/results/classifier/semantic-bugs/instruction/1245543
new file mode 100644
index 000000000..99966ab81
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1245543
@@ -0,0 +1,43 @@
+instruction: 0.966
+other: 0.798
+device: 0.770
+semantic: 0.629
+socket: 0.619
+network: 0.548
+vnc: 0.529
+graphic: 0.455
+boot: 0.437
+mistranslation: 0.417
+assembly: 0.269
+KVM: 0.262
+
+Wrong implementation of SSE4.1 pmovzxbw and similar instructions
+
+QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest.
+
+To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output:
+
+$ ./a.out
+1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0
+
+On QEMU, the output is as follows:
+
+$ ./a.out
+1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+
+QEMU is invoked as:
+
+qemu-system-x86_64 \
+    -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \
+    -serial stdio -no-reboot \
+    -kernel vmlinuz -initrd initrd.img \
+    -netdev user,id=user.0 -device rtl8139,netdev=user.0  -redir tcp:2222::22 \
+    -hda ubuntu-amd64.ext3 \
+    --append "rw console=tty root=/dev/sda"
+
+
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1248168 b/results/classifier/semantic-bugs/instruction/1248168
new file mode 100644
index 000000000..22e04de30
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1248168
@@ -0,0 +1,42 @@
+instruction: 0.820
+graphic: 0.800
+assembly: 0.749
+device: 0.731
+mistranslation: 0.533
+socket: 0.270
+boot: 0.257
+other: 0.250
+semantic: 0.231
+vnc: 0.131
+network: 0.118
+KVM: 0.030
+
+MIPS, self-modifying code and uncached memory
+
+Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region.
+
+For example, when running this code I get unexpected behavior:
+
+   0:	e3000010 	b	0x390
+   4:	00000000 	nop
+	...
+ 380:	00701f40 	mfc0	ra,c0_epc
+ 384:	0400e0bb 	swr	zero,4(ra)
+ 388:	18000042 	eret
+ 38c:	00000000 	nop
+ 390:	25500000 	move	t2,zero
+ 394:	02000b34 	li	t3,0x2
+ 398:	23504b01 	subu	t2,t2,t3
+ 39c:	e9003c0b 	j	0xcf003a4
+ 3a0:	0a004a21 	addi	t2,t2,10
+ 3a4:	ffff0010 	b	0x3a4
+ 3a8:	00000000 	nop
+ 3ac:	00000000 	nop
+
+  I expect that swr instruction in line 384 would change `addi	t2,t2,1`0 to `nop`
+This should work because no cache is used for this memory region.
+
+Can you please provide full reproduction steps rather than just an assembly snippet?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1328996 b/results/classifier/semantic-bugs/instruction/1328996
new file mode 100644
index 000000000..b48ededc8
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1328996
@@ -0,0 +1,25 @@
+instruction: 0.932
+device: 0.871
+mistranslation: 0.798
+graphic: 0.713
+semantic: 0.618
+network: 0.577
+socket: 0.504
+other: 0.463
+vnc: 0.395
+boot: 0.376
+assembly: 0.134
+KVM: 0.107
+
+[AArch64] - blr x30 is handled incorrectly
+
+Whenever x30 is used as the operand for blr, the result will be incorrect.  There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual.  There are two statically linked 64-bit executables in files.tar.gz: good and bad.  The executable "good" uses "blr x9", and the output is what is expected: "func".  The executable "bad" uses "blr x30" and nothing is printed out.  It prints "func" on the actual device.
+
+
+
+I think this should already be fixed in master by commit 1b505f93bcf60 (about a month ago). Can you try a newer QEMU build, please?
+
+
+
+Thanks, Peter.  I just built the latest development build, and it now passes.  Sorry for the false alarm.
+
diff --git a/results/classifier/semantic-bugs/instruction/1376 b/results/classifier/semantic-bugs/instruction/1376
new file mode 100644
index 000000000..3f75ca7c9
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1376
@@ -0,0 +1,28 @@
+instruction: 0.954
+assembly: 0.897
+device: 0.854
+graphic: 0.701
+vnc: 0.674
+socket: 0.609
+network: 0.505
+boot: 0.489
+semantic: 0.444
+KVM: 0.243
+other: 0.223
+mistranslation: 0.191
+
+x86 LSL and LAR fault
+Description of problem:
+From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0xa02e698e741f5a6a");
+    asm("mov rbx, 0x20959ddd7a0aef");
+    asm("lsl ax, bx");
+}
+```
+2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/instruction/1377 b/results/classifier/semantic-bugs/instruction/1377
new file mode 100644
index 000000000..f3d87d4fe
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1377
@@ -0,0 +1,27 @@
+instruction: 0.973
+assembly: 0.847
+device: 0.773
+vnc: 0.768
+graphic: 0.742
+boot: 0.462
+socket: 0.412
+KVM: 0.326
+semantic: 0.321
+network: 0.279
+other: 0.095
+mistranslation: 0.073
+
+x86 CVT* series instructions fault
+Description of problem:
+For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    mmap(0x555555559000, 0x1000, flag, ~~, 0);
+    asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]");
+}
+```
+2. Execute. QEMU crashes but CPU does not.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/instruction/1498 b/results/classifier/semantic-bugs/instruction/1498
new file mode 100644
index 000000000..2ac4b50f4
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1498
@@ -0,0 +1,18 @@
+instruction: 0.978
+graphic: 0.914
+other: 0.851
+device: 0.849
+semantic: 0.841
+mistranslation: 0.800
+network: 0.564
+boot: 0.371
+vnc: 0.362
+socket: 0.166
+assembly: 0.098
+KVM: 0.027
+
+LDC, STC unimplemented in qemu-system-arm
+Description of problem:
+I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected.
+
+The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU.
diff --git a/results/classifier/semantic-bugs/instruction/1574346 b/results/classifier/semantic-bugs/instruction/1574346
new file mode 100644
index 000000000..410bb5bab
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1574346
@@ -0,0 +1,41 @@
+instruction: 0.779
+other: 0.750
+graphic: 0.731
+device: 0.728
+mistranslation: 0.635
+semantic: 0.551
+network: 0.544
+socket: 0.467
+vnc: 0.421
+boot: 0.390
+assembly: 0.341
+KVM: 0.339
+
+TCG: mov to segment register is incorrectly emulated for AMD CPUs
+
+In TCG mode, the effect of:
+
+xorl %eax, %eax
+movl %eax, %gs
+
+is to mark the GS segment unusable and set its base to zero.  After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero.
+
+This is correct for Intel CPUs but is incorrect for AMD CPUs.  On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged.
+
+To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1637 b/results/classifier/semantic-bugs/instruction/1637
new file mode 100644
index 000000000..9656c06fd
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1637
@@ -0,0 +1,14 @@
+instruction: 0.919
+device: 0.840
+graphic: 0.655
+boot: 0.219
+other: 0.214
+vnc: 0.201
+semantic: 0.196
+network: 0.164
+assembly: 0.162
+socket: 0.081
+mistranslation: 0.070
+KVM: 0.044
+
+Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host
diff --git a/results/classifier/semantic-bugs/instruction/1719984 b/results/classifier/semantic-bugs/instruction/1719984
new file mode 100644
index 000000000..909f6f0d9
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1719984
@@ -0,0 +1,27 @@
+instruction: 0.917
+graphic: 0.887
+mistranslation: 0.851
+device: 0.786
+network: 0.762
+semantic: 0.650
+boot: 0.624
+socket: 0.597
+vnc: 0.595
+KVM: 0.312
+other: 0.185
+assembly: 0.157
+
+wrgsbase misemulated in x86_64-softmmu
+
+qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4
+command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true '
+
+On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1.  In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference.
+
+For further data, the faulting instruction is
+f3 48 0f ae df          wrgsbase %rdi
+
+Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d
+
+Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550
+
diff --git a/results/classifier/semantic-bugs/instruction/1737 b/results/classifier/semantic-bugs/instruction/1737
new file mode 100644
index 000000000..3b07da097
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1737
@@ -0,0 +1,62 @@
+instruction: 0.968
+graphic: 0.919
+device: 0.848
+assembly: 0.842
+socket: 0.826
+vnc: 0.774
+network: 0.701
+semantic: 0.687
+boot: 0.686
+mistranslation: 0.642
+other: 0.581
+KVM: 0.346
+
+qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher.
+Description of problem:
+```
+#include <arm_sve.h>
+#include <stdio.h>
+
+#define SZ 32
+
+int main(int argc, char* argv[]) {
+  svbool_t pg = svptrue_b64();
+  uint64_t VL = svcntd();
+
+  fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL);
+
+  int64_t sr[SZ], sx[SZ], sy[SZ];
+  uint64_t ur[SZ], ux[SZ], uy[SZ];
+
+  for (uint64_t i = 0; i < SZ; ++i) {
+    sx[i] = ux[i] = 0;
+    sy[i] = uy[i] = 1024;
+  }
+
+  for (uint64_t i = 0; i < SZ; i+=VL) {
+    fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1);
+
+    svint64_t SX = svld1(pg, sx + i);
+    svint64_t SY = svld1(pg, sy + i);
+    svint64_t SR = svsra(SX, SY, 4);
+    svst1(pg, sr + i, SR);
+
+    svuint64_t UX = svld1(pg, ux + i);
+    svuint64_t UY = svld1(pg, uy + i);
+    svuint64_t UR = svsra(UX, UY, 4);
+    svst1(pg, ur + i, UR);
+  }
+
+  for (uint64_t i = 0; i < SZ; ++i) {
+    fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]);
+  }
+
+  return 0;
+}
+```
+Steps to reproduce:
+1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang.
+2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned)
+3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/instruction/1738434 b/results/classifier/semantic-bugs/instruction/1738434
new file mode 100644
index 000000000..e6167f2d3
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1738434
@@ -0,0 +1,50 @@
+instruction: 0.851
+socket: 0.767
+graphic: 0.763
+device: 0.757
+mistranslation: 0.729
+network: 0.680
+vnc: 0.670
+assembly: 0.666
+other: 0.625
+semantic: 0.586
+KVM: 0.558
+boot: 0.530
+
+CALL FWORD PTR [ESP] handled incorrectly
+
+To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware:
+
+    push 33h
+    push offset _far_call
+    call fword ptr[esp]
+    jmp _ret
+_far_call:
+    retf
+_ret:
+
+32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look:
+
+    push 23h
+    push offset _far_call
+    call fword ptr[esp]
+    jmp _ret
+_far_call:
+    retf
+_ret:
+
+0x23 is a default 32-bit selector for 32-bit processes running under WoW64.
+
+Environment:
+QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img
+Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19
+Host OS: Windows 10 x64 version 1703 build 15063.786
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1751422 b/results/classifier/semantic-bugs/instruction/1751422
new file mode 100644
index 000000000..df415ac99
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1751422
@@ -0,0 +1,71 @@
+instruction: 0.738
+mistranslation: 0.597
+semantic: 0.524
+graphic: 0.506
+socket: 0.497
+other: 0.473
+device: 0.451
+vnc: 0.425
+network: 0.386
+boot: 0.348
+assembly: 0.324
+KVM: 0.292
+
+some instructions translate error in x86
+
+There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on.
+The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it.
+
+Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it.
+
+The patch is In this mail attachments, which is patch for version 2.11.1   target/i386/translate.c.
+The patch is created by diff.
+my English is so poor to explain how the error come, but you can see the patch result to get  it.
+
+
+
+
+
+
+
+
+At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote:
+>Could you please provide some more information about the problem? What's
+>exactly the error? If you've already got a patch, please have a look at
+>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information
+>how to submit it.
+>
+>** Changed in: qemu
+>       Status: New => Incomplete
+>
+>-- 
+>You received this bug notification because you are subscribed to the bug
+>report.
+>https://bugs.launchpad.net/bugs/1751422
+>
+>Title:
+>  some instructions translate error in x86
+>
+>Status in QEMU:
+>  Incomplete
+>
+>Bug description:
+>  There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on.
+>  The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it.
+>
+>To manage notifications about this bug go to:
+>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+We shouldn't really have let this expire, the submitter has a patch attached to the bug.
+
+Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ?
+
+
+I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11.
+
+Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed.
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1751494 b/results/classifier/semantic-bugs/instruction/1751494
new file mode 100644
index 000000000..2e2e48a44
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1751494
@@ -0,0 +1,38 @@
+instruction: 0.878
+graphic: 0.676
+assembly: 0.586
+device: 0.585
+semantic: 0.580
+mistranslation: 0.510
+other: 0.502
+socket: 0.335
+network: 0.320
+vnc: 0.279
+boot: 0.154
+KVM: 0.051
+
+tcg-target.inc.c:3495:no such instruction: `xgetbv'
+
+While building QEMU on Mac OS 10.6.8 I saw this error message:
+tag-target.inc.c:3495:no such instruction: `xgetbv'
+In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code:
+asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0));
+
+https://github.com/asmjit/asmjit/issues/78
+According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. 
+
+Host info:
+Mac OS 10.6.8
+GCC 5.2.0
+
+Additional information:
+This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang.
+
+The exact commit that causes this problem is this:
+
+commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac
+tcg/i386: Add vector operations
+
+This has been fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252
+
diff --git a/results/classifier/semantic-bugs/instruction/1756927 b/results/classifier/semantic-bugs/instruction/1756927
new file mode 100644
index 000000000..3ec2692ab
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1756927
@@ -0,0 +1,47 @@
+instruction: 0.816
+device: 0.753
+boot: 0.666
+mistranslation: 0.622
+semantic: 0.554
+graphic: 0.551
+network: 0.531
+vnc: 0.523
+socket: 0.491
+assembly: 0.407
+KVM: 0.400
+other: 0.370
+
+ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT
+
+When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception.
+
+You'll find attached a minimal example to reproduce the issue (just run 'make all').
+The output I get is:
+
+supervisor
+user
+prefetch
+short-descriptor
+
+The last entry should read 'long-descriptor'.
+
+
+Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69
+Ubuntu verison: 16.04 LTS
+Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi
+
+
+
+I've just sent this patchset:
+http://<email address hidden>/
+which should fix this bug and a couple of others that I noticed with our debug exception handling while I was doing that.
+
+
+thanks Peter ! Any news on the review ?
+
+The patches are in master now.
+
+
+Hi Peter,
+we tested the fix and it work correctly now, thank you very much !
+
diff --git a/results/classifier/semantic-bugs/instruction/1771 b/results/classifier/semantic-bugs/instruction/1771
new file mode 100644
index 000000000..3195f46f5
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1771
@@ -0,0 +1,46 @@
+instruction: 0.977
+graphic: 0.917
+device: 0.843
+socket: 0.778
+semantic: 0.749
+vnc: 0.729
+network: 0.581
+boot: 0.572
+other: 0.534
+mistranslation: 0.523
+assembly: 0.491
+KVM: 0.118
+
+Missing CASA instruction handling for SPARC qemu-user
+Description of problem:
+Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it.
+Steps to reproduce:
+1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31])
+2. qemu-sparc will raise "Illegal instruction"
+Additional information:
+The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space.
+
+```
+diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c
+--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/target/sparc/translate.c      2023-04-01 15:24:18.293176711 +0200
+@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex
+                 case 0x37: /* stdc */
+                     goto ncp_insn;
+ #endif
+-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
+                 case 0x3c: /* V9 or LEON3 casa */
+ #ifndef TARGET_SPARC64
+                     CHECK_IU_FEATURE(dc, CASA);
+@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex
+                     rs2 = GET_FIELD(insn, 27, 31);
+                     cpu_src2 = gen_load_gpr(dc, rs2);
+                     gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd);
++//#endif
+                     break;
+-#endif
+                 default:
+                     goto illegal_insn;
+                 }
+```
diff --git a/results/classifier/semantic-bugs/instruction/1771948 b/results/classifier/semantic-bugs/instruction/1771948
new file mode 100644
index 000000000..636db688b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1771948
@@ -0,0 +1,51 @@
+instruction: 0.898
+other: 0.852
+graphic: 0.837
+semantic: 0.818
+device: 0.763
+network: 0.610
+vnc: 0.606
+socket: 0.601
+mistranslation: 0.540
+assembly: 0.504
+boot: 0.482
+KVM: 0.408
+
+aarch64 msr CNTFRQ_EL0
+
+Hello,
+
+I'm running qemu 2.12 on a raspberry pi 3 with the command:
+
+qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin
+
+On my start file (right in the beginning with the highest EL), the following instructions:
+
+ldr x0 , =19200000
+msr CNTFRQ_EL0, x0
+
+
+and qemu halts on the "msr CNTFRQ_EL0, x0" instruction.
+
+I believe this is not a normal behavior.
+
+Thank you
+
+Mmm, that's not really supposed to happen. Do you have a test guest binary you can attach that I can reproduce with?
+
+
+Looking more closely at this, I think this is because you've passed QEMU a file which it is treating as a Linux kernel. (-kernel treats raw binaries and uimage files as Linux kernels; it treats ELF files as not being Linux kernels). Linux expects to be started in EL2, so although the emulated CPU has EL3, we start your program in EL2. Your program is therefore not running at the highest available exception level, and can't write to CNTFRQ_EL0.
+
+For "bare metal" images where you want to do things at EL3, it may be better to build them as ELF files which are linked to load at address 0. Note that all four cores will start at address zero simultaneously, so you'll need a bit of "pen code" to sort the secondaries out from the primary. https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S might be useful reference. As I understand it, this is how your code would be run on real raspi3 hardware too.
+
+
+Thank you for your reply. Sorry to take so long (was on vacations).
+
+Your comment seems correct to me. I tried with the ELF file instead of the binary file and it worked perfectly (and all the cores were running instead of just core 0).
+
+From my point of view, this bug can be marked as invalid.
+
+Thank you again.
+
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1780 b/results/classifier/semantic-bugs/instruction/1780
new file mode 100644
index 000000000..354a178d0
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1780
@@ -0,0 +1,30 @@
+instruction: 0.971
+graphic: 0.882
+device: 0.724
+network: 0.589
+semantic: 0.561
+vnc: 0.436
+boot: 0.398
+socket: 0.311
+assembly: 0.172
+mistranslation: 0.130
+other: 0.041
+KVM: 0.040
+
+PowerPC mishandles xscmpudp instruction
+Description of problem:
+xscmpudp instruction is mishandled
+Steps to reproduce:
+1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`)
+2. Run the program and expect assertions to pass.
+3. See assertions fail.
+Additional information:
+When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly).  See the offending program:
+```
+pub fn main() {
+    use std::hint::black_box;
+    assert!(black_box(f64::NAN)
+        .clamp(black_box(0f64), black_box(0f64))
+        .is_nan());
+}
+```
diff --git a/results/classifier/semantic-bugs/instruction/1790 b/results/classifier/semantic-bugs/instruction/1790
new file mode 100644
index 000000000..2a0a409bf
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1790
@@ -0,0 +1,42 @@
+instruction: 0.969
+graphic: 0.821
+boot: 0.809
+semantic: 0.738
+device: 0.730
+mistranslation: 0.585
+assembly: 0.543
+network: 0.505
+vnc: 0.500
+other: 0.437
+socket: 0.425
+KVM: 0.068
+
+[AARCH64] STGP instruction is not writing the value of the second register to memory
+Description of problem:
+My application is built with Clang 16 and the option -fsanitize=memtag-stack.
+It means the the MTE protection is activated for the stack.
+The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory.
+The following instruction was not working as expected:
+   18004: 69000895     	stgp	x21, x2, [x4]
+The value of the second register x2 is not transferred to the memory.
+Only x21 is written.
+
+I think that the issue is in trans_STGP().
+We don't call finalize_memop_pair() like we do for in the general trans_STP().
+
+```
+diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c
+index 7d0c8f79a7..f599f3e136 100644
+--- a/target/arm/tcg/translate-a64.c
++++ b/target/arm/tcg/translate-a64.c
+@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a)
+ 
+     tcg_rt = cpu_reg(s, a->rt);
+     tcg_rt2 = cpu_reg(s, a->rt2);
++    mop = a->sz + 1;
++    mop = finalize_memop_pair(s, mop);
+ 
+     assert(a->sz == 3);
+```
+
+With this fix, my OS (Kinibi) is now able to boot.
diff --git a/results/classifier/semantic-bugs/instruction/1793608 b/results/classifier/semantic-bugs/instruction/1793608
new file mode 100644
index 000000000..b6a6faa1b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1793608
@@ -0,0 +1,49 @@
+instruction: 0.899
+mistranslation: 0.794
+graphic: 0.781
+semantic: 0.777
+assembly: 0.747
+device: 0.645
+other: 0.636
+network: 0.605
+socket: 0.600
+vnc: 0.548
+KVM: 0.477
+boot: 0.423
+
+qemu doesn't seem to support lxvwsx for POWER9 target
+
+When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly.
+
+Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit).
+Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series).
+QEMU 3.0.0 is built from source and installed with: sudo make install
+
+The program in question: https://github.com/VectorChief/UniSIMD-assembler
+Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file:
+https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h
+
+Change to the "test" directory and type "make -f simd_make_p64.mk".
+powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt
+Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...)
+The instruction shows up in objdump correctly.
+
+Small clarification to the bug description above.
+
+Host architecture: x86_64 (AMD64)
+Instructions used for building QEMU 3.0.0 from source are here:
+https://github.com/VectorChief/UniSIMD-assembler/blob/master/INSTALL
+
+The command line for emulating POWER9 target is below:
+qemu-ppc64le -cpu POWER9 simd_test.p64_32Lp9 -c 1
+
+With the workaround for lxvwsx instruction turned off (as described above)
+QEMU crashes in s_test08 function of the following common SIMD test file:
+https://github.com/VectorChief/UniSIMD-assembler/blob/master/test/simd_test.cpp
+
+A patch has been posted here:
+https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02218.html
+("ppc/translate: Implement lxvwsx opcode")
+
+Released with QEMU v5.2.0.
+
diff --git a/results/classifier/semantic-bugs/instruction/1818075 b/results/classifier/semantic-bugs/instruction/1818075
new file mode 100644
index 000000000..26b345c17
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1818075
@@ -0,0 +1,133 @@
+instruction: 0.940
+graphic: 0.906
+assembly: 0.878
+other: 0.877
+device: 0.848
+KVM: 0.820
+vnc: 0.809
+network: 0.800
+semantic: 0.791
+socket: 0.778
+mistranslation: 0.773
+boot: 0.655
+
+qemu x86 TCG doesn't support AVX insns
+
+I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU.
+
+Adding input tracing shows that it is likely hanging when dealing with an AVX instruction:
+
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18]
+warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8]
+warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
+
+IN:
+0x4000b4ef3b:  c5 fb 5c ca              vsubsd   %xmm2, %xmm0, %xmm1
+0x4000b4ef3f:  c4 e1 fb 2c d1           vcvttsd2si %xmm1, %rdx
+0x4000b4ef44:  4c 31 e2                 xorq     %r12, %rdx
+0x4000b4ef47:  48 85 d2                 testq    %rdx, %rdx
+0x4000b4ef4a:  79 9e                    jns      0x4000b4eeea
+
+[ hangs ]
+
+Attaching a gdb produces this stacktrace:
+
+(gdb) bt
+#0  canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350
+#1  float64_unpack_canonical (s=0x55a20ff67a88, f=0)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547
+#2  float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776
+#3  0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623
+#4  0x000055a20cfcfea8 in static_code_gen_buffer ()
+#5  0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171
+#6  cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>,
+    cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615
+#7  cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725
+#8  0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93
+#9  0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819
+
+<pm215>	my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever
+
+<rburton> in_asm log just stopped with this as the last line
+<rburton> 0x4000b4ef4a:  79 9e                    jns      0x4000b4eeea
+
+
+Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx).
+
+We should ideally:
+ * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program)
+ * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer)
+
+
+If I may be so free:
+
+It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization.
+
+My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc.
+Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward.
+
+If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS.
+
+Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal):
+
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
+
+And this is emulating a lowly Penryn CPU with the required CPU flags for macOS:
+-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc
+
+Attempting to emulate a more feature laden intel CPU results in even more issues.
+
+I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it.
+
+We do care about emulation; but as always with open source software projects, the parts that get more care and attention are the parts that people are either paid to work on or are personally interested in. x86 guest emulation in particular is not very well maintained (though it is better than some targets), because mostly people are happy to use x86 hardware, and adding support for emulation of large new architectural features like AVX is a lot of work. If you would like to help improve x86 guest emulation, you are welcome to submit patches to fix bugs or add new features. Merely saying "X should be better and you should somehow magically find three months worth of developer time to make it so" doesn't really do anything to move the situation forwards.
+
+
+QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. Thus simply declaring that an open source project, must support something won't magically make it happen.
+
+IOW, the lack of coverage of newer x86 instructions is largely a reflection of the relative priorities of the current pool of contributors and where/what they feel are the best places/features to spend their time on.
+
+If any person does want to work on improving x86 TCG though, the project would happily receive patches, and existing contributors can offer guidance & advice along the way to help get to a successful outcome.
+
+
+Of course it’s open source, I get that. When I say „xyz should be done“ then in the sense of „2+2 should be 4“ not in the sense of „you must implement xyz right now“ ;)
+
+Nonetheless, if you run e.g. on an ARM platform the command 
+
+qemu-system-x86_64 -cpu help
+
+then it shouldn’t list a slew of CPUs as „available“ that clearly aren’t working.
+
+It should then list fully implemented CPUs separately from partially implemented CPUs (if listing them at all), and if it does list incomplete implementations, it should indicate what’s missing.
+It’s just a horrible user experience, if based on such output, one spends significant time trying to get some emulation running, only to then discover from runtime error messages, that an „available“ CPU isn’t actually available.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/164
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1820686 b/results/classifier/semantic-bugs/instruction/1820686
new file mode 100644
index 000000000..f7fd19f6d
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1820686
@@ -0,0 +1,25 @@
+instruction: 0.949
+device: 0.824
+network: 0.809
+other: 0.742
+socket: 0.724
+semantic: 0.691
+vnc: 0.683
+mistranslation: 0.678
+graphic: 0.598
+boot: 0.498
+KVM: 0.321
+assembly: 0.305
+
+risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0'
+
+QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded.
+
+I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this.
+
+
+
+Thanks.  If you spin a full patch (ie, "git commit -s" and then "git show") I can drop it on riscv-qemu-3.1, our backports branch.  Otherwise hopefully we got the bug via the decodetree conversion.
+
+Since this bug isn't present in the decodetree version of the riscv decoder, we might as well just close this as fix-released; we won't be doing more point-releases of QEMU versions as old as 3.1.
+
diff --git a/results/classifier/semantic-bugs/instruction/1824344 b/results/classifier/semantic-bugs/instruction/1824344
new file mode 100644
index 000000000..9886d36a4
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1824344
@@ -0,0 +1,71 @@
+instruction: 0.928
+assembly: 0.842
+device: 0.543
+semantic: 0.396
+network: 0.367
+socket: 0.356
+other: 0.327
+boot: 0.303
+vnc: 0.251
+graphic: 0.236
+mistranslation: 0.196
+KVM: 0.008
+
+x86: retf or iret pagefault sets wrong error code
+
+With a x86_64 or i386 guest, non-KVM, when trying to execute a
+"iret/iretq/retf" instruction in userspace with invalid stack pointer
+(under a protected mode OS, like Linux), wrong bits are set in the
+pushed error code; bit 2 is not set, indicating the error comes from
+kernel space.
+
+If the guest OS is using this flag to decide whether this was a kernel
+or user page fault, it will mistakenly decide a kernel has irrecoverably
+faulted, possibly causing guest OS panic.
+
+
+How to reproduce the problem a guest (non-KVM) Linux:
+Note, on recent Linux kernel version, this needs a CPU with SMAP support
+(eg. -cpu max)
+
+$ cat tst.c
+int main()
+{
+__asm__ volatile (
+"mov $0,%esp\n"
+"retf"
+);
+return 0;
+}
+
+$ gcc tst.c
+$ ./a.out
+Killed
+
+
+"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle
+kernel NULL pointer dereference...", but it has "recovered" by killing
+the faulting process (see attached screenshot).
+
+
+Using self-compiled qemu from git:
+commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD)
+Author: Peter Maydell <email address hidden>
+Date:   Wed Apr 10 15:38:59 2019 +0100
+
+    Update version for v4.0.0-rc3 release
+    
+    Signed-off-by: Peter Maydell <email address hidden>
+
+
+
+This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler)
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/265
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1824778 b/results/classifier/semantic-bugs/instruction/1824778
new file mode 100644
index 000000000..d9e3e95db
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1824778
@@ -0,0 +1,30 @@
+instruction: 0.756
+device: 0.493
+semantic: 0.280
+graphic: 0.275
+network: 0.264
+other: 0.245
+boot: 0.202
+vnc: 0.194
+socket: 0.151
+mistranslation: 0.124
+KVM: 0.054
+assembly: 0.052
+
+PowerPC64: tlbivax does not work for addresses above 4G
+
+The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address.
+Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue.
+
+I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change.
+
+Issue can be seen in all version of QEMU.
+
+
+This is an automated cleanup. This bug report has been moved
+to QEMU's new bug tracker on gitlab.com and thus gets marked
+as 'expired' now. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/52
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1828867 b/results/classifier/semantic-bugs/instruction/1828867
new file mode 100644
index 000000000..05260e5d1
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1828867
@@ -0,0 +1,48 @@
+instruction: 0.527
+device: 0.454
+socket: 0.435
+mistranslation: 0.388
+assembly: 0.285
+network: 0.264
+vnc: 0.258
+graphic: 0.231
+semantic: 0.225
+boot: 0.171
+other: 0.169
+KVM: 0.124
+
+QEmu translation is incorrect when using REX in combination with LAHF/SAHF
+
+When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly.
+These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers.
+On hardware the REX prefix doesn't effect behaviour of these instructions at all.
+QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage.
+
+I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed"
+
+
+
+Here's also a basic test that can be run on hardware and have rflags and rsp inspected after each instruction just to see how hardware doesn't effect it.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+This is still relevant.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/130
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1832422 b/results/classifier/semantic-bugs/instruction/1832422
new file mode 100644
index 000000000..39c39a63d
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1832422
@@ -0,0 +1,33 @@
+instruction: 0.815
+device: 0.667
+network: 0.510
+socket: 0.486
+graphic: 0.457
+semantic: 0.453
+vnc: 0.413
+boot: 0.294
+other: 0.278
+mistranslation: 0.276
+assembly: 0.233
+KVM: 0.224
+
+SSE CMP ops with 8bit immediate throw sigill with oversized byte
+
+The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized.
+
+Test op that I found this on is here `66 0f c2 c0 d1          cmppd  xmm0,xmm0,0xd1`
+According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant)
+Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask.
+
+I have a small patch that fixes the issue for the SSE variant.
+
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/184
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1863247 b/results/classifier/semantic-bugs/instruction/1863247
new file mode 100644
index 000000000..072da78e3
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1863247
@@ -0,0 +1,33 @@
+instruction: 0.742
+device: 0.668
+graphic: 0.540
+semantic: 0.501
+other: 0.498
+mistranslation: 0.393
+socket: 0.384
+network: 0.383
+vnc: 0.341
+boot: 0.254
+assembly: 0.250
+KVM: 0.178
+
+AArch64 EXT instruction for V register does not clear MSB side bits
+
+On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value.
+
+Example
+ext v0.16b, v1.16b v2.16b, 8
+
+After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width.
+
+Yep.
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=78cedfabd53b
+
+
+Thank you for bug fix.
+I found trn1, trn2, zip1, zip2, uz1, uz2 instructions seem to have same bug.
+
+All of those, and tbl, tbx, ins, are fixed in the three subsequent commits.
+
diff --git a/results/classifier/semantic-bugs/instruction/1889288 b/results/classifier/semantic-bugs/instruction/1889288
new file mode 100644
index 000000000..4b1ea1874
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1889288
@@ -0,0 +1,26 @@
+instruction: 0.757
+mistranslation: 0.724
+semantic: 0.599
+graphic: 0.519
+assembly: 0.467
+other: 0.455
+device: 0.440
+socket: 0.381
+vnc: 0.348
+network: 0.348
+boot: 0.182
+KVM: 0.137
+
+aarch64 BICS instruciton doesn't set flags
+
+When reading the source for translate-a64.c here:
+
+https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783
+
+I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug.
+
+The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1.
+
+
+Oh yes I see. Sorry for the false report.
+
diff --git a/results/classifier/semantic-bugs/instruction/1898954 b/results/classifier/semantic-bugs/instruction/1898954
new file mode 100644
index 000000000..77df51de8
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1898954
@@ -0,0 +1,73 @@
+instruction: 0.923
+mistranslation: 0.880
+boot: 0.854
+graphic: 0.850
+other: 0.845
+KVM: 0.778
+device: 0.762
+semantic: 0.752
+socket: 0.648
+network: 0.624
+assembly: 0.575
+vnc: 0.567
+
+x86 f1 opcode hangs qemu
+
+I have qemu installed and running in linux and windows
+in linux i execute the following simple code in real mode of cpu in my vm
+90 nop
+90 nop
+90 nop
+f1         ;this should conjure up my interrupt handler from ivt int 1
+--------- end of code ----
+it works properly in vbox,qemu linux,and even in my boot loder
+on a real platform
+   it doeas not work fine in windows 10 (32 bit efi) based qemu
+---
+all of the below was retyped there may be typo
+so onwards to the flawed software 
+********** for qemu-system-x86_64.exe **********
+info version 
+4.2.0v4.2.0.11797-g2890edc853-dirty
+********** for qemu-system-i386.exe **********
+info version 
+4.2.0v4.2.0.11797-g2890edc853-dirty
+***********************************************
+my startup code is
+"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc
+---
+also same flaw if i change above section to
+"d:\programs\qemu\qemu-system-i386.exe"
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/instruction/1901 b/results/classifier/semantic-bugs/instruction/1901
new file mode 100644
index 000000000..33ec55668
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1901
@@ -0,0 +1,32 @@
+instruction: 0.968
+graphic: 0.871
+device: 0.723
+semantic: 0.696
+other: 0.517
+network: 0.432
+socket: 0.404
+vnc: 0.392
+mistranslation: 0.243
+boot: 0.231
+assembly: 0.079
+KVM: 0.079
+
+qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction
+Description of problem:
+Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0).  Other VIS instructions I tried seem to be OK (I have not tried all of them).
+
+The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications.
+Steps to reproduce:
+1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc:
+   ```
+   sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c
+   ```
+2. Run it in qemu-sparc64:
+   ```
+   qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16
+   ```
+3. Observe almost all tests fail.
+
+   Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results.
+Additional information:
+[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c)
diff --git a/results/classifier/semantic-bugs/instruction/1912934 b/results/classifier/semantic-bugs/instruction/1912934
new file mode 100644
index 000000000..f487e30df
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1912934
@@ -0,0 +1,78 @@
+instruction: 0.655
+device: 0.618
+semantic: 0.589
+mistranslation: 0.555
+graphic: 0.466
+socket: 0.360
+vnc: 0.325
+assembly: 0.276
+network: 0.262
+boot: 0.230
+other: 0.223
+KVM: 0.145
+
+QEMU emulation of fmadds instruction on powerpc64le is buggy
+
+The attached program test-fmadds.c tests the fmadds instruction on powerpc64le.
+
+Result on real hardware (POWER8E processor):
+$ ./a.out ; echo $?
+0
+
+Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04:
+$ ./a.out ; echo $?
+32
+
+Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04:
+$ ./a.out ; echo $?
+32
+
+Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ).
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+The situation is still the same in QEMU 6.0.0.
+
+$ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static
+$ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $?
+32
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/312
+
+
diff --git a/results/classifier/semantic-bugs/instruction/1915027 b/results/classifier/semantic-bugs/instruction/1915027
new file mode 100644
index 000000000..4df7ceb4b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1915027
@@ -0,0 +1,27 @@
+instruction: 0.816
+assembly: 0.781
+graphic: 0.759
+other: 0.744
+device: 0.634
+semantic: 0.632
+mistranslation: 0.442
+vnc: 0.284
+network: 0.181
+boot: 0.140
+socket: 0.116
+KVM: 0.044
+
+RISC-V 64, CPUs do ilegal 0x00 write with SMP
+
+When QEMU is runt like this:
+
+qemu-system-riscv64 -d unimp,guest_errors -smp 8
+
+Other harts will do a illegal write on address 0x00.
+
+This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute.
+
+Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage.
+
+If you load a kernel you will not see the error messages.
+
diff --git a/results/classifier/semantic-bugs/instruction/1916269 b/results/classifier/semantic-bugs/instruction/1916269
new file mode 100644
index 000000000..45a2ef615
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1916269
@@ -0,0 +1,70 @@
+instruction: 0.884
+socket: 0.821
+graphic: 0.779
+device: 0.775
+other: 0.721
+network: 0.656
+semantic: 0.654
+vnc: 0.626
+mistranslation: 0.626
+boot: 0.615
+assembly: 0.473
+KVM: 0.297
+
+TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
+
+If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2.
+
+Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067
+
+    /* simple MMX/SSE operation */
+    if (s->flags & HF_TS_MASK) {
+        gen_exception(s, EXCP07_PREX, pc_start - s->cs_base);
+        return;
+    }
+
+However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit.
+
+The code sequence in question is:
+0xffffffff8105a4de <+126>:	f2 48 0f 38 f1 de	crc32q %rsi,%rbx
+0xffffffff8105a4e4 <+132>:	f2 48 0f 38 f1 ca	crc32q %rdx,%rcx.
+
+This should work even with the FPU disabled.
+
+Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch.
+Thanks!
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427
+
diff --git a/results/classifier/semantic-bugs/instruction/1926759 b/results/classifier/semantic-bugs/instruction/1926759
new file mode 100644
index 000000000..753b9e4d4
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1926759
@@ -0,0 +1,73 @@
+instruction: 0.938
+semantic: 0.770
+graphic: 0.694
+other: 0.656
+device: 0.644
+vnc: 0.552
+assembly: 0.506
+socket: 0.491
+network: 0.398
+boot: 0.365
+mistranslation: 0.349
+KVM: 0.297
+
+WFI instruction results in unhandled CPU exception
+
+Hi 
+
+I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following  crash log.
+
+qemu: unhandled CPU exception 0x10001 - aborting
+R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec
+R04=00010a28 R05=00010158 R06=00087460 R07=00010158
+R08=00000000 R09=00000000 R10=00085b7c R11=408009f4
+R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8
+PSR=60000010 -ZC- A usr32
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12
+
+WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks.
+
+Regards
+Muhui
+
+Please provide a test case binary and your QEMU command line.
+
+
+Oh, and the QEMU version you're using as well, please.
+
+
+cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2
+
+QEMU version: qemu-arm version 5.1.0
+
+Sorry that I didn't test it on the latest version of QEMU.
+
+Crash repros on current QEMU.
+
+This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly.
+
+
+The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but 
+"WFI is a NOP" is a valid architectural implementation anyway.)
+
+
+I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. 
+
+It seems ARM manual does not defined the implementation of function EnterLowPowerState();  However, before executing this instruction, there are some checks like below:
+
+if PSTATE.EL == EL0 then
+     // Check for traps described by the OS which may be EL1 or EL2.
+     AArch32.CheckForWFxTrap(EL1, FALSE);
+
+I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment.
+
+We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist.
+
+
+Should be fixed by:
+https://<email address hidden>/
+
+
+Fix has been merged:
+https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a
+
diff --git a/results/classifier/semantic-bugs/instruction/1955 b/results/classifier/semantic-bugs/instruction/1955
new file mode 100644
index 000000000..17cd3a9de
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1955
@@ -0,0 +1,39 @@
+instruction: 0.950
+graphic: 0.840
+semantic: 0.801
+device: 0.645
+other: 0.493
+socket: 0.420
+network: 0.394
+mistranslation: 0.346
+boot: 0.280
+vnc: 0.269
+assembly: 0.183
+KVM: 0.107
+
+powerpc instruction 'mffsl' not emulated on POWER8
+Description of problem:
+Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction.
+See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28
+and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57
+
+In the emulated Debian system, executables that make use of this instruction crash with SIGILL.
+Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction.
+
+From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>:
+  "Nicely, it turns out that the 'mffsl' instruction will decode to
+   'mffs' on architectures older than "power9" because the additional
+   bits set for 'mffsl' are "don't care" for 'mffs'.  'mffs' is a superset
+   of 'mffsl'."
+
+This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL.
+Steps to reproduce:
+1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc.
+2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8.
+3. Or compile and run the attached foo.c and run it under QEMU.
+Additional information:
+[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz)
+
+[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz)
+
+[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c)
diff --git a/results/classifier/semantic-bugs/instruction/1958 b/results/classifier/semantic-bugs/instruction/1958
new file mode 100644
index 000000000..8240e159e
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1958
@@ -0,0 +1,34 @@
+instruction: 0.931
+mistranslation: 0.877
+graphic: 0.858
+device: 0.805
+vnc: 0.766
+semantic: 0.679
+socket: 0.488
+other: 0.383
+KVM: 0.381
+network: 0.360
+boot: 0.359
+assembly: 0.268
+
+PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE]
+Description of problem:
+When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception.
+Additional information:
+In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function:
+   
+```
+if (FIELD_EX64(env->msr, MSR, CE)) {
+    /* Critical doorbell */
+    if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) {   <- move this part from (async_deliver != 0)
+        return PPC_INTERRUPT_CDOORBELL;
+     }
+     /* External critical interrupt */
+     if (env->pending_interrupts & PPC_INTERRUPT_CEXT) {
+         return PPC_INTERRUPT_CEXT;
+     }
+}
+```
+ 
+
+And it seems to work in my case.
diff --git a/results/classifier/semantic-bugs/instruction/2074 b/results/classifier/semantic-bugs/instruction/2074
new file mode 100644
index 000000000..475ecd6df
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2074
@@ -0,0 +1,33 @@
+instruction: 0.908
+graphic: 0.839
+device: 0.680
+boot: 0.672
+semantic: 0.448
+other: 0.389
+mistranslation: 0.233
+vnc: 0.171
+socket: 0.147
+network: 0.129
+assembly: 0.101
+KVM: 0.093
+
+riscv64  cannot use the mret instruction to jump to the address corresponding to s mode
+Description of problem:
+I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800.
+and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened.
+It shows:
+[DEBUG]  Exception:          Instruction access fault
+[DEBUG]  Hart ID:            0
+[DEBUG]  Previous mode:      machine
+[DEBUG]  Bad instruction pc: 0x8103f7c0
+[DEBUG]  Bad address:        0x00000000
+[DEBUG]  Stored ra:          0x8103f7b8
+[DEBUG]  Stored sp:          0x82032f08
+Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret".
+So I can not jump to my kernel's load address.
+I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address?
+Steps to reproduce:
+1.download qemu
+2.download coreboot
+Additional information:
+When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000.
diff --git a/results/classifier/semantic-bugs/instruction/2089 b/results/classifier/semantic-bugs/instruction/2089
new file mode 100644
index 000000000..4241b84e5
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2089
@@ -0,0 +1,40 @@
+instruction: 0.901
+semantic: 0.855
+graphic: 0.833
+device: 0.746
+vnc: 0.500
+assembly: 0.466
+network: 0.405
+socket: 0.335
+boot: 0.172
+mistranslation: 0.117
+KVM: 0.086
+other: 0.022
+
+aarch64: incorrect emulation of sqshrn instruction
+Description of problem:
+`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware.
+Steps to reproduce:
+1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64
+2. Observe two failures
+
+```
+[ RUN      ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1
+frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure
+Expected equality of these values:
+  res1
+    Which is: 4294967188
+  MakeUInt128(0x94U, 0U)
+    Which is: 148
+[  FAILED  ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms)
+[ RUN      ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1
+frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure
+Expected equality of these values:
+  res3
+    Which is: 4294967168
+  MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL)
+    Which is: 128
+[  FAILED  ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms)
+```
+Additional information:
+[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861)
diff --git a/results/classifier/semantic-bugs/instruction/2175 b/results/classifier/semantic-bugs/instruction/2175
new file mode 100644
index 000000000..874c3bcde
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2175
@@ -0,0 +1,51 @@
+instruction: 0.883
+device: 0.776
+graphic: 0.745
+assembly: 0.701
+network: 0.686
+vnc: 0.644
+other: 0.619
+socket: 0.611
+mistranslation: 0.593
+KVM: 0.567
+semantic: 0.514
+boot: 0.511
+
+Intel BLSI CF computation bug
+Description of problem:
+CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed.
+Steps to reproduce:
+1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work.
+```
+int main() {
+  __asm__ (
+    "movq $0x1, %r8\n"
+    "mov $0xedbf530a, %r9\n"
+    "push $0x1\n"
+    "popf\n"
+    "blsi %r9d, %r8d\n"
+    "pushf\n"
+    "pop %rax\n"
+    "pop %rbp\n"
+    "ret\n"
+  );
+
+  return 0;
+}
+```
+2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3.
+```
+$ ./example.bin
+$ echo $?
+3
+```
+3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2.
+```
+$ ./qemu-x86_64 ./example.bin
+$ echo $?
+2
+```
+
+The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/instruction/2248 b/results/classifier/semantic-bugs/instruction/2248
new file mode 100644
index 000000000..ae3a6196e
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2248
@@ -0,0 +1,49 @@
+instruction: 0.883
+graphic: 0.837
+assembly: 0.815
+device: 0.776
+vnc: 0.746
+network: 0.743
+socket: 0.741
+other: 0.592
+boot: 0.547
+semantic: 0.539
+KVM: 0.475
+mistranslation: 0.466
+
+qemu-aarch64: wrong execution result when executing the code
+Description of problem:
+The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5.
+
+```c
+// foo.c
+#include <stdio.h>
+#include <stdint.h>
+
+int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c);
+
+int main() {
+    int64_t ret = callme(0, 0, 0, 1, 2);
+    printf("%ld\n", ret);
+    return 0;
+}
+```
+
+```s
+// foo.S
+.global callme
+callme:
+  cmp   x2, x3
+  cset  x12, lt
+  and   w11, w12, #0xff
+  cmp   w11, #0x0
+  csetm x14, ne
+  lsr   x13, x14, x4
+  sxtb  x0, w13
+  ret
+```
+Steps to reproduce:
+1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`)
+2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result
+Additional information:
+- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug.
diff --git a/results/classifier/semantic-bugs/instruction/2302 b/results/classifier/semantic-bugs/instruction/2302
new file mode 100644
index 000000000..dd607123b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2302
@@ -0,0 +1,38 @@
+instruction: 0.900
+graphic: 0.787
+device: 0.692
+assembly: 0.569
+socket: 0.543
+semantic: 0.466
+vnc: 0.348
+network: 0.348
+mistranslation: 0.316
+other: 0.274
+boot: 0.240
+KVM: 0.084
+
+qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks
+Description of problem:
+I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help.
+Steps to reproduce:
+1. Compile SPEC CPU 2017 basic Perlbench binary. 
+2. Use the above command line to run it.
+Additional information:
+I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this:
+```
+----------------
+IN: Perl_lex_start
+0x555555678a79:  48 89 83 a8 00 00 00     movq     %rax, 0xa8(%rbx)
+0x555555678a80:  e9 01 ff ff ff           jmp      0x555555678986
+
+----------------
+IN: Perl_lex_start
+0x555555678986:  48 8b 50 10              movq     0x10(%rax), %rdx
+0x55555567898a:  41 83 e4 16              andl     $0x16, %r12d
+0x55555567898e:  48 89 93 d0 00 00 00     movq     %rdx, 0xd0(%rbx)
+0x555555678995:  48 89 93 c0 00 00 00     movq     %rdx, 0xc0(%rbx)
+0x55555567899c:  62                       .byte    0x62
+
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)
+```
diff --git a/results/classifier/semantic-bugs/instruction/2317 b/results/classifier/semantic-bugs/instruction/2317
new file mode 100644
index 000000000..0acfd4575
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2317
@@ -0,0 +1,51 @@
+instruction: 0.951
+device: 0.841
+socket: 0.672
+graphic: 0.665
+vnc: 0.650
+network: 0.620
+semantic: 0.613
+assembly: 0.550
+boot: 0.545
+mistranslation: 0.480
+other: 0.332
+KVM: 0.048
+
+SH4:  ADDV instruction not emulated properly
+Description of problem:
+ADDV opcode is emulated incorrectly.
+
+The documentation says:
+
+`ADDV Rm, Rn        Rn + Rm -> Rn, overflow -> T`
+
+What Qemu actually emulates:
+
+`ADDV Rm, Rn        Rn + Rm -> Rm, overflow -> T`
+Steps to reproduce:
+```c
+#include <stdio.h>
+
+int main(void)
+{
+	register unsigned int a asm("r8") = 0x7fffffff;
+	register unsigned int b asm("r9") = 1;
+	register unsigned int c asm("r10");
+
+	asm volatile("clrt\n"
+		     "addv %2,%0\n"
+		     "movt %1\n"
+		     : "+r"(a), "=r"(c) : "r"(b) :);
+
+	printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c);
+
+	return 0;
+}
+
+```
+Additional information:
+Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints:
+`Values: a=0x80000000 b=0x1 c=0x1`
+
+Running with Qemu (and GCC 13.0), the same program prints:
+`Values: a=0x7fffffff b=0x80000000 c=0x1`
diff --git a/results/classifier/semantic-bugs/instruction/2318 b/results/classifier/semantic-bugs/instruction/2318
new file mode 100644
index 000000000..3defce0d6
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2318
@@ -0,0 +1,47 @@
+instruction: 0.871
+device: 0.679
+graphic: 0.495
+assembly: 0.485
+vnc: 0.479
+semantic: 0.460
+boot: 0.291
+socket: 0.281
+network: 0.239
+other: 0.133
+mistranslation: 0.100
+KVM: 0.006
+
+SH4: SUBV instruction not emulated properly
+Description of problem:
+SUBV opcode is emulated incorrectly.
+
+The documentation says:
+
+`SUBV Rm, Rn        Rn - Rm -> Rn, underflow -> T`
+
+Qemu seems to perform the subtraction correctly, but will not detect an underflow.
+Steps to reproduce:
+```c
+#include <stdio.h>
+
+int main(void)
+{
+	register unsigned int a asm("r8") = 0x80000001;
+	register unsigned int b asm("r9") = 0x2;
+	register unsigned int c asm("r10");
+
+	asm volatile("subv %2,%0\n"
+		     "movt %1\n"
+		     : "+r"(a), "=r"(c) : "r"(b) :);
+
+	printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c);
+
+	return 0;
+}
+```
+Additional information:
+Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints:
+`Values: a=0x7fffffff b=0x2 c=0x1`
+
+Running with Qemu (and GCC 13.0), the same program prints:
+`Values: a=0x7fffffff b=0x2 c=0x0`
diff --git a/results/classifier/semantic-bugs/instruction/2386 b/results/classifier/semantic-bugs/instruction/2386
new file mode 100644
index 000000000..96e88af3c
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2386
@@ -0,0 +1,56 @@
+instruction: 0.967
+graphic: 0.899
+socket: 0.812
+device: 0.808
+vnc: 0.803
+network: 0.759
+assembly: 0.688
+mistranslation: 0.640
+semantic: 0.624
+other: 0.616
+boot: 0.615
+KVM: 0.565
+
+RISCV - Incorrect behaviour of the SLL instruction
+Description of problem:
+`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view):
+
+> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register
+rs1 by the shift amount held in the lower 5 bits of register rs2.
+
+This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left:
+
+```python
+correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1)
+incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1)
+```
+Steps to reproduce:
+1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf`
+
+```c
+#include <stdint.h>
+#include <stdio.h>
+
+int main() {
+  uint64_t a = 0x69C99AB9B9401024;
+  uint64_t b = 0xDB4D6868655C3585;
+  uint64_t c;
+
+  asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a));
+
+  printf("s8      : %lx\n", c);
+  printf("expected: %lx\n", 0xb4d6868655c35850);
+
+  return 0;
+}
+```
+
+2. Run qemu: `./qemu-riscv64 ./repro.elf`
+3. You will see the output and what the result of the computation should really be:
+
+```
+s8      : 55c3585000000000
+expected: b4d6868655c35850
+```
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/instruction/2497 b/results/classifier/semantic-bugs/instruction/2497
new file mode 100644
index 000000000..ccc110c51
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2497
@@ -0,0 +1,16 @@
+instruction: 0.895
+device: 0.848
+graphic: 0.685
+semantic: 0.655
+network: 0.531
+boot: 0.293
+socket: 0.291
+assembly: 0.286
+vnc: 0.283
+other: 0.236
+mistranslation: 0.145
+KVM: 0.015
+
+m68k: fpu: FPIAR register is not implemented
+Description of problem:
+QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure.
diff --git a/results/classifier/semantic-bugs/instruction/2500 b/results/classifier/semantic-bugs/instruction/2500
new file mode 100644
index 000000000..4939d31cc
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2500
@@ -0,0 +1,17 @@
+instruction: 0.946
+graphic: 0.818
+device: 0.817
+semantic: 0.810
+assembly: 0.807
+mistranslation: 0.739
+network: 0.738
+other: 0.715
+socket: 0.510
+boot: 0.257
+vnc: 0.154
+KVM: 0.115
+
+m68k: mmu: 68030 mmu instructions are missing
+Description of problem:
+The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??).
+QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu.
diff --git a/results/classifier/semantic-bugs/instruction/2865 b/results/classifier/semantic-bugs/instruction/2865
new file mode 100644
index 000000000..993bac92e
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2865
@@ -0,0 +1,65 @@
+instruction: 0.901
+assembly: 0.741
+mistranslation: 0.694
+device: 0.653
+graphic: 0.618
+socket: 0.439
+vnc: 0.390
+network: 0.364
+other: 0.326
+boot: 0.235
+semantic: 0.210
+KVM: 0.187
+
+loongarch64: wrong implementation of `xvldi` instruction
+Description of problem:
+Consider this sample program.
+
+```c++
+#include <cstdio>
+#include <cstdint>
+#include <lsxintrin.h>
+#include <lasxintrin.h>
+
+void dump_u32(__m256i x) {
+    uint32_t tmp[32/4];
+    __lasx_xvst(x, tmp, 0);
+    putchar('[');
+    for (int i=0; i < 32/4; i++) {
+        if (i > 0) {
+            putchar(' ');
+        }
+
+        printf("%08x", tmp[i]);
+    }
+    puts("]");
+}
+
+int main() {
+    __m256i const1 = __lasx_xvldi(-3832);
+    dump_u32(const1);
+}
+```
+
+The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected:
+
+```
+[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800]
+```
+
+The same program run under Qemu prints:
+
+```
+[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000]
+```
+Additional information:
+I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`.
+
+```c
+    case 1:
+        /* data: {2{16'0, imm[7:0], 8'0}} */
+        data = (t << 24) | (t << 8);
+        break;
+```
+
+There should be `(t << (8+32)) | t << 8`.
diff --git a/results/classifier/semantic-bugs/instruction/2971 b/results/classifier/semantic-bugs/instruction/2971
new file mode 100644
index 000000000..2ee49f8b8
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/2971
@@ -0,0 +1,57 @@
+instruction: 0.834
+vnc: 0.780
+device: 0.770
+assembly: 0.671
+network: 0.667
+socket: 0.623
+graphic: 0.579
+semantic: 0.515
+boot: 0.473
+other: 0.425
+KVM: 0.396
+mistranslation: 0.282
+
+loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi
+Description of problem:
+Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes.
+
+The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates.
+
+`target/loongarch/insns.decode`:
+
+```
+vldi             0111 00111110 00 ............. .....     @v_i13
+xvldi            0111 01111110 00 ............. .....     @v_i13
+```
+
+This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`:
+
+```C
+    /*
+     * imm bit [11:8] is mode, mode value is 0-12.
+     * other values are invalid.
+     */
+```
+
+However, an assertion error is raised when this condition is violated and qemu crashes:
+
+```
+**
+ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
+Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
+```
+
+On hardware (Loongson 3A5000), these instructions cause a SIGILL.
+Steps to reproduce:
+1. compile the `test_inv_vldi` test program for loongarch64 (see additional information)
+2. run `qemu-loongarch64-static ./test_inv_vldi`
+Additional information:
+I will post a patch for this issue to the mailing list soon.
+
+`test_inv_vldi` source code:
+
+```C
+int main(int argc, char** argv) {
+    asm volatile(".4byte 0x73e3a000");    
+}
+```
diff --git a/results/classifier/semantic-bugs/instruction/361 b/results/classifier/semantic-bugs/instruction/361
new file mode 100644
index 000000000..ee26ed4b0
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/361
@@ -0,0 +1,14 @@
+instruction: 0.829
+mistranslation: 0.634
+semantic: 0.465
+graphic: 0.432
+vnc: 0.253
+device: 0.243
+boot: 0.163
+KVM: 0.134
+other: 0.106
+assembly: 0.014
+network: 0.006
+socket: 0.006
+
+-cpu host results in unsupported AVX512 instructions
diff --git a/results/classifier/semantic-bugs/instruction/390 b/results/classifier/semantic-bugs/instruction/390
new file mode 100644
index 000000000..61671b821
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/390
@@ -0,0 +1,14 @@
+instruction: 0.961
+assembly: 0.706
+device: 0.526
+graphic: 0.370
+semantic: 0.361
+boot: 0.196
+KVM: 0.175
+mistranslation: 0.162
+vnc: 0.116
+network: 0.058
+socket: 0.029
+other: 0.019
+
+target/ppc: atomic path of Load Quadword instruction require address with write permission
diff --git a/results/classifier/semantic-bugs/instruction/514 b/results/classifier/semantic-bugs/instruction/514
new file mode 100644
index 000000000..f973fe24b
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/514
@@ -0,0 +1,38 @@
+instruction: 0.922
+device: 0.778
+graphic: 0.745
+semantic: 0.631
+mistranslation: 0.623
+vnc: 0.549
+assembly: 0.514
+boot: 0.468
+socket: 0.457
+network: 0.427
+other: 0.370
+KVM: 0.335
+
+MTE reports false positive for "str" instruction with the SP as the base register.
+Description of problem:
+When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access.
+Steps to reproduce:
+Clang version: clang version 12.0.1. 
+I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code:
+```
+0000000000000c14 <test_func>:
+     c14:       a9bc7bfd        stp     x29, x30, [sp, #-64]!
+     c18:       f9000bf7        str     x23, [sp, #16]
+     ...
+```
+Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch.
+When cpu executes firs instruction "stp     x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault":
+ESR_EL1=0x96000051.
+
+According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access:
+```
+A Tag Unchecked access will be generated for a load or store that uses either of the following:
+• A base register only, with the SP as the base register.
+• A base register plus immediate offset addressing form, with the SP as the base register.
+```
+Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/instruction/799 b/results/classifier/semantic-bugs/instruction/799
new file mode 100644
index 000000000..b6de1812e
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/799
@@ -0,0 +1,60 @@
+instruction: 0.871
+graphic: 0.858
+assembly: 0.798
+device: 0.740
+vnc: 0.609
+socket: 0.576
+network: 0.552
+other: 0.445
+boot: 0.333
+semantic: 0.288
+mistranslation: 0.231
+KVM: 0.164
+
+TCG Optimizer crashes on AArch64 SVE2 instruction
+Description of problem:
+QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction:
+```
+Unrecognized operation 145 in do_constant_folding.
+../tcg/optimize.c:458: tcg fatal error
+```
+Steps to reproduce:
+1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img))
+```asm
+.org 0x0
+entry:
+    mrs     x1, cptr_el3
+    orr     x9, x1, #0x100
+    msr     cptr_el3,   x9
+
+    msr     cptr_el2,   xzr
+
+    mov     x1, #0x3
+    mrs     x9, cpacr_el1
+    bfi     x9, x1, #16, #2
+    bfi     x9, x1, #20, #2
+    msr     cpacr_el1,  x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el1, x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el2, x9
+
+    mov     x9, 512
+    mov     x0, x9
+    asr     x0, x0, 7
+    sub     x9, x0, #1
+    msr     zcr_el3, x9
+
+    uqxtnt  z11.s, z22.d
+```
+2. Execute it using the command line given above.
+Additional information:
+I tested latest master as well, and the problem persists.
diff --git a/results/classifier/semantic-bugs/instruction/824 b/results/classifier/semantic-bugs/instruction/824
new file mode 100644
index 000000000..cf7795167
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/824
@@ -0,0 +1,25 @@
+instruction: 0.888
+graphic: 0.848
+device: 0.834
+mistranslation: 0.623
+vnc: 0.563
+semantic: 0.474
+socket: 0.455
+assembly: 0.442
+network: 0.345
+other: 0.321
+boot: 0.225
+KVM: 0.024
+
+x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524)
+Description of problem:
+`Qemu` produces a Translation block of 4 instructions:
+```
+0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
+0x0000558a53039fff: 0f           (nothing)
+0x0000558a53039ffc: 83f806       (cmp eax, 0x6)
+0x0000558a53039fff: 0f8f1e050000 (jnle 0x524)
+```
+This problem occurs several time with different addresses but the same pattern:
+- 1st and 3th instructions are the same (both addresses and opcodes);
+- 2nd is the prefix of the 4th (same addresses).
diff --git a/results/classifier/semantic-bugs/instruction/826 b/results/classifier/semantic-bugs/instruction/826
new file mode 100644
index 000000000..3ef3962e4
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/826
@@ -0,0 +1,29 @@
+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.
diff --git a/results/classifier/semantic-bugs/instruction/925 b/results/classifier/semantic-bugs/instruction/925
new file mode 100644
index 000000000..8d42ab6dc
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/925
@@ -0,0 +1,31 @@
+instruction: 0.864
+graphic: 0.770
+device: 0.746
+network: 0.517
+other: 0.426
+assembly: 0.416
+vnc: 0.416
+socket: 0.394
+semantic: 0.338
+boot: 0.325
+KVM: 0.311
+mistranslation: 0.233
+
+AArch64 SVE2 LD/ST instructions segfault on MMIO addresses
+Description of problem:
+During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state:
+```
+(gdb) p $x17
+$1 = 0xffffffe2
+(gdb) p $z26.s.u
+$2 = {0x0 <repeats 16 times>}
+(gdb) p $p2
+$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0}
+```
+QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device.
+Additional information:
+A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices.
+
+<details><summary>Reproducer seed for my future self</summary>
+S6008340160849309262|Q|cd4t|pq|w5|lK124
+</details>
diff --git a/results/classifier/semantic-bugs/instruction/984 b/results/classifier/semantic-bugs/instruction/984
new file mode 100644
index 000000000..0458e2758
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/984
@@ -0,0 +1,36 @@
+instruction: 0.978
+device: 0.870
+semantic: 0.790
+network: 0.753
+socket: 0.751
+vnc: 0.711
+graphic: 0.657
+boot: 0.586
+assembly: 0.462
+other: 0.443
+KVM: 0.336
+mistranslation: 0.140
+
+QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word
+Description of problem:
+~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word.
+
+```
+IN = 1234.567890 (0x40934a4584f4c6e7)
+OUT = 1234.567871 (0x40099a522c0000000000)
+```
+
+This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now).
+
+Prior to the offending commit:
+
+```
+IN = 1234.567890 (0x40934a4584f4c6e7)
+OUT = 1234.567890 (0x40099a522c27a6373800)
+```
+
+This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`).
+Steps to reproduce:
+Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result.
+Additional information:
+See https://github.com/zephyrproject-rtos/sdk-ng/issues/461
diff --git a/results/classifier/semantic-bugs/mistranslation/1613817 b/results/classifier/semantic-bugs/mistranslation/1613817
new file mode 100644
index 000000000..a275fd7fb
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/1613817
@@ -0,0 +1,130 @@
+mistranslation: 0.697
+instruction: 0.679
+other: 0.653
+KVM: 0.623
+graphic: 0.617
+vnc: 0.599
+device: 0.558
+semantic: 0.550
+boot: 0.543
+assembly: 0.543
+network: 0.536
+socket: 0.523
+
+x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack
+
+This test program:
+
+# compile with: gcc -nostartfiles -nostdlib
+_start:         .globl  _start
+                mov     %ss,%eax
+                push    %rax
+                push    %rsp
+                pushf
+                mov     %cs,%eax
+                push    %rax
+                mov     $0x1234567812345678,%rax
+                push    %rax
+//qemu bug: ip=1234567812345678, should be ip=0000000000400abc:
+                iretq
+1:
+                jmp     1b
+
+should segfault on IRET instruction because return address on stack is invalid
+(it is not canonical). And it does, both on native CPU and in qemu.
+But there is a difference: on native CPU, it fails before instruction is executed,
+IOW: saved IP points to the failed IRET:
+
+# strace -i ./bad_ip_in_iret 
+[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0
+[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+ ^^^^^^^^^^^^^^^^-NOTE THIS
+[????????????????] +++ killed by SIGSEGV (core dumped) +++
+
+
+In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed:
+
+/ # strace -i ./bad_ip_in_iret
+[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0
+[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+ ^^^^^^^^^^^^^^^^-NOTE THIS
+[????????????????] +++ killed by SIGSEGV +++
+Segmentation fault
+
+Thus, the emulation is not the same as real CPU.
+
+This is not specific to IRET, the same happens with "far return" LRET,
+and with ordinary RET instructions as well.
+In qemu:
+
+/ # strace -i ./bad_ip_in_lret
+[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0
+[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+[????????????????] +++ killed by SIGSEGV +++
+Segmentation fault
+/ # strace -i ./bad_ip_in_ret
+[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0
+[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+[????????????????] +++ killed by SIGSEGV +++
+Segmentation fault
+
+# qemu-system-x86_64 --version
+QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008 Fabrice Bellard
+
+Running it like this:
+
+qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio -append "panic=1"
+
+(i.e. no KVM, no unusual options)
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+Still happens with qemu 5.1.92
+
+I imagine the fix should be inserted here:
+
+static inline void helper_ret_protected(CPUX86State *env, int shift,
+                                        int is_iret, int addend,
+                                        uintptr_t retaddr)
+{
+    uint32_t new_cs, new_eflags, new_ss;
+    uint32_t new_es, new_ds, new_fs, new_gs;
+    uint32_t e1, e2, ss_e1, ss_e2;
+    int cpl, dpl, rpl, eflags_mask, iopl;
+    target_ulong ssp, sp, new_eip, new_esp, sp_mask;
+
+#ifdef TARGET_X86_64
+    if (shift == 2) {
+        sp_mask = -1;
+    } else
+#endif
+    {
+        sp_mask = get_sp_mask(env->segs[R_SS].flags);
+    }
+    sp = env->regs[R_ESP];
+    ssp = env->segs[R_SS].base;
+    new_eflags = 0; /* avoid warning */
+#ifdef TARGET_X86_64
+    if (shift == 2) {
+        POPQ_RA(sp, new_eip, retaddr);
+if (new_eip is not canonical) raise_exception_err_ra();  <==== HERE
+        POPQ_RA(sp, new_cs, retaddr);
+        new_cs &= 0xffff;
+        if (is_iret) {
+            POPQ_RA(sp, new_eflags, retaddr);
+        }
+    } else
+#endif
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/125
+
+
diff --git a/results/classifier/semantic-bugs/mistranslation/1830872 b/results/classifier/semantic-bugs/mistranslation/1830872
new file mode 100644
index 000000000..ea6c495b1
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/1830872
@@ -0,0 +1,612 @@
+mistranslation: 0.745
+other: 0.741
+vnc: 0.722
+instruction: 0.712
+KVM: 0.677
+semantic: 0.670
+graphic: 0.668
+device: 0.664
+assembly: 0.656
+boot: 0.623
+network: 0.606
+socket: 0.594
+
+AARCH64 to ARMv7 mistranslation in TCG
+
+The following guest code:
+
+  https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S
+
+implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
+Development Kit II) library function. (CopyMem() basically has memmove()
+semantics, to provide a standard C analog here.) The relevant functions
+are InternalMemCopyMem() and __memcpy().
+
+When TCG translates this aarch64 code to x86_64, everything works fine.
+
+When TCG translates this aarch64 code to ARMv7, the destination area of
+the translated CopyMem() function becomes corrupted -- it differs from
+the intended source contents. Namely, in every 4096 byte block, the
+8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
+instead of receiving the intended source value.
+
+I'm attaching two hexdumps of the same destination area:
+
+- "good.txt" is a hexdump of the destination area when CopyMem() was
+  translated to x86_64,
+
+- "bad.txt" is a hexdump of the destination area when CopyMem() was
+  translated to ARMv7.
+
+In order to assist with the analysis of this issue, I disassembled the
+aarch64 binary with "objdump". Please find the listing in
+"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
+hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.
+
+And, I ran the guest on the ARMv7 host with "-d
+in_asm,op,op_opt,op_ind,out_asm". Please find the log in
+"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.
+
+The TBs that correspond to (parts of) the InternalMemCopyMem() and
+__memcpy() functions are scattered over the TCG log file, but the offset
+between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
+TBs in the TCG log, can be determined from the fact that there is a
+single prfm instruction in the entire binary. The instruction's offset
+is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
+function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
+difference (= the load address of DxeCore.efi) is 0x472a7000.
+
+QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
+'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).
+
+The reproducer command line is (on an ARMv7 host):
+
+  qemu-system-aarch64 \
+    -display none \
+    -machine virt,accel=tcg \
+    -nodefaults \
+    -nographic \
+    -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
+    -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
+    -cpu cortex-a57 \
+    -chardev stdio,signal=off,mux=on,id=char0 \
+    -mon chardev=char0,mode=readline \
+    -serial chardev:char0
+
+The apparent symptom is an assertion failure *in the guest*, such as
+
+> ASSERT [DxeCore]
+> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
+> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength
+
+but that is only a (distant) consequence of the CopyMem()
+mistranslation, and resultant destination area corruption.
+
+Originally reported in the following two mailing list messages:
+- http://<email address hidden>
+- http://<email address hidden>
+
+
+
+Possibly related:
+[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
+https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
+
+(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686)
+
+Note to self: try to reprodouce the present issue with QEMU built at eed5664238ea^ -- this LP has originally been filed about the tree at a4f667b67149, and that commit contains eed5664238ea. So checking at eed5664238ea^ might reveal a difference.
+
+
+Laszlo Ersek (Red Hat) <email address hidden> writes:
+
+> Possibly related:
+> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
+> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
+>
+> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
+> QEMU is built for i686)
+>
+> Note to self: try to reprodouce the present issue with QEMU built at
+> eed5664238ea^ -- this LP has originally been filed about the tree at
+> a4f667b67149, and that commit contains eed5664238ea. So checking at
+> eed5664238ea^ might reveal a difference.
+
+Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
+cases.
+
+--
+Alex Bennée
+
+
+
+Alex Bennée <email address hidden> writes:
+
+> Laszlo Ersek (Red Hat) <email address hidden> writes:
+>
+>> Possibly related:
+>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
+>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
+>>
+>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
+>> QEMU is built for i686)
+>>
+>> Note to self: try to reprodouce the present issue with QEMU built at
+>> eed5664238ea^ -- this LP has originally been filed about the tree at
+>> a4f667b67149, and that commit contains eed5664238ea. So checking at
+>> eed5664238ea^ might reveal a difference.
+>
+> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
+> cases.
+
+Actually I do see something with i386 host running the aarch64 memory
+test (although so far not with a armv7 host):
+
+  ./qemu-system-aarch64  -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory
+
+Gives:
+
+  Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED
+
+--
+Alex Bennée
+
+
+When running on 32 bit TCG backends a wide unaligned load ends up
+truncating data before returning to the guest. We specifically have
+the return type as uint64_t to avoid any premature truncation so we
+should use the same for the interim types.
+
+Hopefully fixes #1830872
+
+Signed-off-by: Alex Bennée <email address hidden>
+---
+ accel/tcg/cputlb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+index cdcc3771020..b796ab1cbea 100644
+--- a/accel/tcg/cputlb.c
++++ b/accel/tcg/cputlb.c
+@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+         && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+                     >= TARGET_PAGE_SIZE)) {
+         target_ulong addr1, addr2;
+-        tcg_target_ulong r1, r2;
++        uint64_t r1, r2;
+         unsigned shift;
+     do_unaligned_access:
+         addr1 = addr & ~(size - 1);
+-- 
+2.20.1
+
+
+
+I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea.
+
+В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
+> When running on 32 bit TCG backends a wide unaligned load ends up
+> truncating data before returning to the guest. We specifically have
+> the return type as uint64_t to avoid any premature truncation so we
+> should use the same for the interim types.
+> 
+> Hopefully fixes #1830872
+> 
+> Signed-off-by: Alex Bennée <email address hidden>
+> ---
+>  accel/tcg/cputlb.c | 2 +-
+>  1 file changed, 1 insertion(+), 1 deletion(-)
+> 
+> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+> index cdcc3771020..b796ab1cbea 100644
+> --- a/accel/tcg/cputlb.c
+> +++ b/accel/tcg/cputlb.c
+> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+>          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+>                      >= TARGET_PAGE_SIZE)) {
+>          target_ulong addr1, addr2;
+> -        tcg_target_ulong r1, r2;
+> +        uint64_t r1, r2;
+>          unsigned shift;
+>      do_unaligned_access:
+>          addr1 = addr & ~(size - 1);
+
+Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ?
+
+I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler ..
+probably x86-64 testing on i686 requires either docker (I don't have this
+) or 'real' cross-compiler (build with glibc support).
+
+
+Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks!
+
+I managed to tweak the memory test enough to detect the failure on aarch64-on-armv7 and I the attached patch fixes it. Could you please double check with your test case?
+
+В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а):
+> I managed to tweak the memory test enough to detect the failure on
+> aarch64-on-armv7 and I the attached patch fixes it. Could you please
+> double check with your test case?
+> 
+
+
+Hm, I manually applied path from LP(git diff disliked copypasted patch), 
+so for now git diff in qemu tree shows:
+
+diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+index cdcc377102..b796ab1cbe 100644
+--- a/accel/tcg/cputlb.c
++++ b/accel/tcg/cputlb.c
+@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+         && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+                     >= TARGET_PAGE_SIZE)) {
+         target_ulong addr1, addr2;
+-        tcg_target_ulong r1, r2;
++        uint64_t r1, r2;
+         unsigned shift;
+     do_unaligned_access:
+         addr1 = addr & ~(size - 1);
+lines 1-13/13 (END)                          
+
+---------
+
+but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg
+still hangs at 'booting the kernel" (it decompress OK)
+
+I make distclean'ed source tree and reconfigured it:
+ ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg  --cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0"
+
+next, make -j 5 and test.
+
+Hm.
+
+I tried debug switches, it seems to hang a bit differently for two runs:
+
+x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm 
+
+=====================
+
+IN:
+0xffffffff810e8a63:  48 83 c3 64              addq     $0x64, %rbx
+0xffffffff810e8a67:  eb c2                    jmp      0xffffffff810e8a2b
+
+OP:
+ ld_i32 tmp18,env,$0xfffffff0
+ movi_i32 tmp19,$0x0
+ brcond_i32 tmp18,tmp19,lt,$L0
+
+ ---- ffffffff810e8a63 0000000000000000
+ movi_i32 tmp2,$0x64
+ movi_i32 tmp3,$0x0
+ mov_i32 tmp0,rbx_0
+ mov_i32 tmp1,rbx_1
+ add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3
+ mov_i32 rbx_0,tmp0
+ mov_i32 rbx_1,tmp1
+ mov_i32 cc_src_0,tmp2
+ mov_i32 cc_src_1,tmp3
+ mov_i32 cc_dst_0,tmp0
+ mov_i32 cc_dst_1,tmp1
+ discard cc_src2_0
+ discard cc_src2_1
+ discard cc_op
+
+ ---- ffffffff810e8a67 0000000000000009
+ movi_i32 cc_op,$0x9
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a2b
+ movi_i32 tmp7,$0xffffffff
+ st_i32 tmp6,env,$0x80
+ st_i32 tmp7,env,$0x84
+ exit_tb $0xf2f1c080
+ set_label $L0
+ exit_tb $0xf2f1c083
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
+ movi_i32 tmp19,$0x0                      pref=0xff
+ brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
+
+ ---- ffffffff810e8a63 0000000000000000
+ movi_i32 tmp2,$0x64                      pref=0xff
+ movi_i32 tmp3,$0x0                       pref=0xff
+ add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3  dead: 2 3  pref=0xff,0xff
+ mov_i32 rbx_0,tmp0                       sync: 0  dead: 1  pref=0xff
+ mov_i32 rbx_1,tmp1                       sync: 0  dead: 1  pref=0xff
+ mov_i32 cc_src_0,tmp2                    sync: 0  dead: 0 1  pref=0xff
+ mov_i32 cc_src_1,tmp3                    sync: 0  dead: 0 1  pref=0xff
+ mov_i32 cc_dst_0,rbx_0                   sync: 0  dead: 0 1  pref=0xff
+ mov_i32 cc_dst_1,rbx_1                   sync: 0  dead: 0 1  pref=0xff
+ discard cc_src2_0                        pref=0xff
+ discard cc_src2_1                        pref=0xff
+ discard cc_op                            pref=0xff mov_i32 cc_dst_0,tmp0
+ mov_i32 cc_dst_1,tmp1
+ discard cc_src2_0
+ discard cc_src2_1
+ discard cc_op
+
+ ---- ffffffff810e8a55 0000000000000021
+ movi_i32 cc_op,$0x21
+ movi_i32 tmp20,$0x0
+ movi_i32 tmp21,$0x0
+ brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a57
+ movi_i32 tmp7,$0xffffffff
+ st_i32 tmp6,env,$0x80
+ st_i32 tmp7,env,$0x84
+ exit_tb $0xf2f1c180
+ set_label $L1
+ goto_tb $0x1
+ movi_i32 tmp6,$0x810e8a63
+ movi_i32 tmp7,$0xffffffff
+ st_i32 tmp6,env,$0x80
+ st_i32 tmp7,env,$0x84
+ exit_tb $0xf2f1c181
+ set_label $L0
+ exit_tb $0xf2f1c183
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
+ movi_i32 tmp19,$0x0                      pref=0xff
+ brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
+
+ ---- ffffffff810e8a4c 0000000000000000
+
+ ---- ffffffff810e8a52 0000000000000000
+ movi_i32 tmp1,$0x0                       pref=0xff
+ movi_i32 tmp0,$0x64                      pref=0xff
+ mov_i32 r14_0,tmp0                       sync: 0  dead: 1  pref=0xf8
+ mov_i32 r14_1,tmp1                       sync: 0  dead: 1  pref=0xf8
+ call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op  sync: 0 1  dead: 0 1 2 3 4 5 6 7 8  pref=none,none
+ mov_i32 cc_dst_0,r14_0                   sync: 0  dead: 0 1  pref=0xff
+ mov_i32 cc_dst_1,r14_1                   sync: 0  dead: 0 1  pref=0xffУбито
+
+(killed by me)
+
+==================
+
+IN:
+0xffffffff810e8a61:  eb ef                    jmp      0xffffffff810e8a52
+
+OP:
+ ld_i32 tmp18,env,$0xfffffff0
+ movi_i32 tmp19,$0x0
+ brcond_i32 tmp18,tmp19,lt,$L0
+
+ ---- ffffffff810e8a61 0000000000000000
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a52
+ movi_i32 tmp7,$0xffffffff
+ st_i32 tmp6,env,$0x80
+ st_i32 tmp7,env,$0x84
+ exit_tb $0xf2f22900
+ set_label $L0
+ exit_tb $0xf2f22903
+
+OP after optimization and liveness analysis:
+ ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
+ movi_i32 tmp19,$0x0                      pref=0xff
+ brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
+
+ ---- ffffffff810e8a61 0000000000000000
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a52                pref=0xff
+ movi_i32 tmp7,$0xffffffff                pref=0xff
+ st_i32 tmp6,env,$0x80                    dead: 0
+ st_i32 tmp7,env,$0x84                    dead: 0 1
+ exit_tb $0xf2f22900
+ set_label $L0
+ exit_tb $0xf2f22903
+
+OUT: [size=56]
+0xf2f22980:  8b 5d f0                 movl     -0x10(%ebp), %ebx
+0xf2f22983:  85 db                    testl    %ebx, %ebx
+0xf2f22985:  0f 8c 23 00 00 00        jl       0xf2f229ae
+0xf2f2298b:  e9 00 00 00 00           jmp      0xf2f22990
+0xf2f22990:  c7 85 80 00 00 00 52 8a  movl     $0x810e8a52, 0x80(%ebp)
+0xf2f22998:  0e 81
+0xf2f2299a:  c7 85 84 00 00 00 ff ff  movl     $0xffffffff, 0x84(%ebp)
+0xf2f229a2:  ff ff
+0xf2f229a4:  b8 00 29 f2 f2           movl     $0xf2f22900, %eax
+0xf2f229a9:  e9 69 46 c9 ff           jmp      0xf2bb7017
+0xf2f229ae:  b8 03 29 f2 f2           movl     $0xf2f22903, %eax
+0xf2f229b3:  e9 5f 46 c9 ff           jmp      0xf2bb7017
+
+----------------
+IN:
+0xffffffff810e8a52:  49 ff ce                 decq     %r14
+0xffffffff810e8a55:  74 0c                    je       0xffffffff810e8a63
+
+OP:
+ ld_i32 tmp18,env,$0xfffffff0
+ movi_i32 tmp19,$0x0
+ brcond_i32 tmp18,tmp19,lt,$L0
+
+ ---- ffffffff810e8a52 0000000000000000
+ mov_i32 tmp0,r14_0
+ mov_i32 tmp1,r14_1
+ mov_i32 tmp0,r14_0
+ mov_i32 tmp1,r14_1
+ movi_i32 tmp20,$0xffffffff
+ movi_i32 tmp21,$0xffffffff
+ add2_i32 tmp0,tmp1,tmp0,tmp1,tmp20,tmp21
+ mov_i32 r14_0,tmp0
+ mov_i32 r14_1,tmp1
+ call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op
+ mov_i32 cc_dst_0,tmp0
+ mov_i32 cc_dst_1,tmp1
+ discard cc_src2_0
+ discard cc_src2_1
+ discard cc_op
+
+ ---- ffffffff810e8a55 0000000000000021 mov_i32 cc_dst_0,r14_0                   sync: 0  dead: 1  pref=0xff
+ mov_i32 cc_dst_1,r14_1                   sync: 0  dead: 1  pref=0xff
+ discard cc_src2_0                        pref=0xff
+ discard cc_src2_1                        pref=0xff
+ discard cc_op                            pref=0xff
+
+ ---- ffffffff810e8a55 0000000000000021
+ movi_i32 cc_op,$0x21                     sync: 0  dead: 0  pref=0xff
+ movi_i32 tmp20,$0x0                      pref=0xff
+ movi_i32 tmp21,$0x0                      pref=0xff
+ brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1  dead: 0 1 2 3
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a57                pref=0xff
+ movi_i32 tmp7,$0xffffffff                pref=0xff
+ st_i32 tmp6,env,$0x80                    dead: 0
+ st_i32 tmp7,env,$0x84                    dead: 0 1
+ exit_tb $0xf2f229c0
+ set_label $L1
+ goto_tb $0x1
+ movi_i32 tmp6,$0x810e8a63                pref=0xff movi_i32 cc_op,$0x9                      sync: 0  dead: 0  pref=0xff
+ goto_tb $0x0
+ movi_i32 tmp6,$0x810e8a2b                pref=0xff
+ movi_i32 tmp7,$0xffffffff                pref=0xff
+ st_i32 tmp6,env,$0x80                    dead: 0
+ st_i32 tmp7,env,$0x84                    dead: 0 1
+ exit_tb $0xf2f22b40
+ set_label $L0
+ exit_tb $0xf2f22b43
+
+OUT: [size=116]
+0xf2f22bc0:  8b 5d f0                 movl     -0x10(%ebp), %ebx
+0xf2f22bc3:  85 db                    testl    %ebx, %ebx
+0xf2f22bc5:  0f 8c 5f 00 00 00        jl       0xf2f22c2a
+0xf2f22bcb:  8b 5d 18                 movl     0x18(%ebp), %ebx
+0xf2f22bce:  8b 75 1c                 movl     0x1c(%ebp), %esi
+0xf2f22bd1:  83 c3 64                 addl     $0x64, %ebx
+0xf2f22bd4:  83 d6 00                 adcl     $0, %esi
+0xf2f22bd7:  89 5d 18                 movl     %ebx, 0x18(%ebp)
+Убито
+
+=============================
+
+try kernel I use (it works with qemu compiiled under 64-bit Slackware, and also with kvm on 32-bit x86)
+
+sha256sum /boot/bzImage-4.12.0-x64
+b4183376de17e8ea7a25094b7a526e99bcb8339b8703090684c93e0e0a50d284  /boot/bzImage-4.12.0-x64
+
+
+(+Igor)
+
+On 06/03/19 17:01, Alex Bennée wrote:
+> When running on 32 bit TCG backends a wide unaligned load ends up
+> truncating data before returning to the guest. We specifically have
+> the return type as uint64_t to avoid any premature truncation so we
+> should use the same for the interim types.
+> 
+> Hopefully fixes #1830872
+> 
+> Signed-off-by: Alex Bennée <email address hidden>
+> ---
+>  accel/tcg/cputlb.c | 2 +-
+>  1 file changed, 1 insertion(+), 1 deletion(-)
+> 
+> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+> index cdcc3771020..b796ab1cbea 100644
+> --- a/accel/tcg/cputlb.c
+> +++ b/accel/tcg/cputlb.c
+> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+>          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+>                      >= TARGET_PAGE_SIZE)) {
+>          target_ulong addr1, addr2;
+> -        tcg_target_ulong r1, r2;
+> +        uint64_t r1, r2;
+>          unsigned shift;
+>      do_unaligned_access:
+>          addr1 = addr & ~(size - 1);
+> 
+
+Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af:
+
+Tested-by: Laszlo Ersek <email address hidden>
+
+Thanks!
+Laszlo
+
+
+
+Andrew Randrianasulu <email address hidden> writes:
+
+> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
+>> When running on 32 bit TCG backends a wide unaligned load ends up
+>> truncating data before returning to the guest. We specifically have
+>> the return type as uint64_t to avoid any premature truncation so we
+>> should use the same for the interim types.
+>>
+>> Hopefully fixes #1830872
+>>
+>> Signed-off-by: Alex Bennée <email address hidden>
+>> ---
+>>  accel/tcg/cputlb.c | 2 +-
+>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>
+>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+>> index cdcc3771020..b796ab1cbea 100644
+>> --- a/accel/tcg/cputlb.c
+>> +++ b/accel/tcg/cputlb.c
+>> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+>>          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+>>                      >= TARGET_PAGE_SIZE)) {
+>>          target_ulong addr1, addr2;
+>> -        tcg_target_ulong r1, r2;
+>> +        uint64_t r1, r2;
+>>          unsigned shift;
+>>      do_unaligned_access:
+>>          addr1 = addr & ~(size - 1);
+>
+> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my
+> bug is separate from #1830872 ?
+
+I think you've hit two - one of which we have just fixed. With my
+expanded memory test on i386 I'm seeing a hang but it's ok @
+pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp
+move and other i386 Werror stuff is proving painful.
+
+>
+> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler ..
+> probably x86-64 testing on i686 requires either docker (I don't have this
+> ) or 'real' cross-compiler (build with glibc support).
+
+
+--
+Alex Bennée
+
+
+On Mon,  3 Jun 2019 16:01:20 +0100
+Alex Bennée <email address hidden> wrote:
+
+> When running on 32 bit TCG backends a wide unaligned load ends up
+> truncating data before returning to the guest. We specifically have
+> the return type as uint64_t to avoid any premature truncation so we
+> should use the same for the interim types.
+> 
+> Hopefully fixes #1830872
+> 
+> Signed-off-by: Alex Bennée <email address hidden>
+
+Fixes arm/virt bios-tables-test for me, so
+
+Tested-by: Igor Mammedov <email address hidden>
+
+> ---
+>  accel/tcg/cputlb.c | 2 +-
+>  1 file changed, 1 insertion(+), 1 deletion(-)
+> 
+> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
+> index cdcc3771020..b796ab1cbea 100644
+> --- a/accel/tcg/cputlb.c
+> +++ b/accel/tcg/cputlb.c
+> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
+>          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
+>                      >= TARGET_PAGE_SIZE)) {  
+>          target_ulong addr1, addr2;
+> -        tcg_target_ulong r1, r2;
+> +        uint64_t r1, r2;
+>          unsigned shift;
+>      do_unaligned_access:
+>          addr1 = addr & ~(size - 1);
+
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b
+
diff --git a/results/classifier/semantic-bugs/mistranslation/1861404 b/results/classifier/semantic-bugs/mistranslation/1861404
new file mode 100644
index 000000000..f905e83ae
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/1861404
@@ -0,0 +1,223 @@
+mistranslation: 0.825
+instruction: 0.821
+assembly: 0.797
+other: 0.797
+device: 0.782
+graphic: 0.773
+socket: 0.740
+network: 0.740
+semantic: 0.730
+KVM: 0.709
+boot: 0.708
+vnc: 0.697
+
+AVX instruction VMOVDQU implementation error for YMM registers
+
+Hi,
+
+Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739.
+
+The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes).
+It works with XMM registers (16 bytes) though.
+
+See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes.
+
+```
+user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror
+
+user@ubuntu ~/Qemu % ./ymm
+00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+
+user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm
+00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+```
+
+This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`).
+
+Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register.
+
+
+```
+static void gen_sse(CPUX86State *env, DisasContext *s, int b,
+                    target_ulong pc_start, int rex_r)
+{
+        [...]
+        case 0x26f: /* movdqu xmm, ea */
+            if (mod != 3) {
+                gen_lea_modrm(env, s, modrm);
+                gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg]));
+            } else { 
+        [...]
+```
+
+```
+static inline void gen_ldo_env_A0(DisasContext *s, int offset)
+{
+    int mem_index = s->mem_index;
+    tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ);
+    tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0)));
+    tcg_gen_addi_tl(s->tmp0, s->A0, 8);
+    tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ);
+    tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1)));
+}
+```
+
+
+
+Note: Qemu has been built with the following commands:
+```
+% ./configure --target-list=x86_64-linux-user && make
+OR
+% ./configure --target-list=x86_64-linux-user --enable-avx2 && make
+```
+
+On Friday, January 31, 2020, Alex Bennée <email address hidden> wrote:
+
+> ** Tags added: tcg testcase
+>
+> --
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1861404
+>
+> Title:
+>   AVX instruction VMOVDQU implementation error for YMM registers
+>
+>
+If I remember well, there is no support for AVX instructions in linux-user
+mode.
+
+If that is true, how come handling of unsupported instruction went that far?
+
+Did you try other AVX instructions?
+
+Aleksandar
+
+
+
+
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Hi,
+>
+>   Tested with Qemu 4.2.0, and with git version
+>   bddff6f6787c916b0e9d63ef9e4d442114257739.
+>
+>   The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers
+> (32 bytes).
+>   It works with XMM registers (16 bytes) though.
+>
+>   See the attached test case `ymm.c`: when copying from memory-to-ymm0
+>   and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the
+>   first 16 of the total 32 bytes.
+>
+>   ```
+>   user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror
+>
+>   user@ubuntu ~/Qemu % ./ymm
+>   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17
+> 18 19 1A 1B 1C 1D 1E 1F
+>
+>   user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm
+>   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00
+> 00 00 00 00 00 00 00 00
+>   ```
+>
+>   This seems to be because in `translate.c > gen_sse()`, the case
+>   handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always
+>   performs a 16 bytes copy using two 8 bytes load and store operations
+>   (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`).
+>
+>   Instead, the `gen_ldo_env_A0` function should generate a copy with a
+>   size corresponding to the used register.
+>
+>
+>   ```
+>   static void gen_sse(CPUX86State *env, DisasContext *s, int b,
+>                       target_ulong pc_start, int rex_r)
+>   {
+>           [...]
+>           case 0x26f: /* movdqu xmm, ea */
+>               if (mod != 3) {
+>                   gen_lea_modrm(env, s, modrm);
+>                   gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg]));
+>               } else {
+>           [...]
+>   ```
+>
+>   ```
+>   static inline void gen_ldo_env_A0(DisasContext *s, int offset)
+>   {
+>       int mem_index = s->mem_index;
+>       tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ);
+>       tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg,
+> ZMM_Q(0)));
+>       tcg_gen_addi_tl(s->tmp0, s->A0, 8);
+>       tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ);
+>       tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg,
+> ZMM_Q(1)));
+>   }
+>   ```
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1861404/+subscriptions
+>
+>
+
+
+Because the sse code is sloppy, and it was interpreted
+as the sse instruction movdqu.
+
+AVX support was coded for GSoC last year,
+
+https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html
+
+but it has not been completely reviewed and committed.
+
+There is no support for AVX in master.
+
+Thanks for your answers.
+
+I thought the fact that there was not any warning/exception meant that VMOVDQU was supported, but if it's mistakenly interpreted as MOVDQU then I understand.
+
+I read the mailing list messages on the AVX GSoC you point out, but couldn't find any branch where this work is located. Is there a non-released version of this that can be tested?
+
+If I understand correctly, Qemu (or more precisely TCG) supports x86 SIMD instructions up to SSE4.1, but not AVX/AVX2/AVX-512?
+
+Thanks.
+
+Hi,
+
+I also noticed that the 4.2.0 release changelog mentions support for some AVX512 instructions.
+
+https://wiki.qemu.org/ChangeLog/4.2#x86
+```
+Support for AVX512 BFloat16 extensions.
+```
+
+Is this support in TCG or in another component?
+If so, it would mean that TCG support some AVX512 instructions but not AVX. 
+
+Also, allow me to ask again, where can I find the work of last year's GSoC on AVX support for TCG?
+
+> AVX support was coded for GSoC last year,
+> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html
+
+Thanks.
+
+The "AVX512 BFloat16" patch is for KVM support.
+
+As for finding the GSoC work, please follow that link,
+and the ones buried inside that.  There are hundreds
+of patches involved.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/132
+
+
diff --git a/results/classifier/semantic-bugs/mistranslation/266 b/results/classifier/semantic-bugs/mistranslation/266
new file mode 100644
index 000000000..4824b4c1d
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/266
@@ -0,0 +1,14 @@
+mistranslation: 0.986
+instruction: 0.937
+device: 0.742
+semantic: 0.592
+network: 0.416
+other: 0.357
+graphic: 0.350
+boot: 0.238
+socket: 0.112
+assembly: 0.101
+vnc: 0.084
+KVM: 0.032
+
+'mtfsf' instruction can clear FI incorrectly
diff --git a/results/classifier/semantic-bugs/mistranslation/427 b/results/classifier/semantic-bugs/mistranslation/427
new file mode 100644
index 000000000..c11b42a46
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/427
@@ -0,0 +1,14 @@
+mistranslation: 0.924
+instruction: 0.887
+device: 0.849
+network: 0.621
+boot: 0.337
+socket: 0.323
+graphic: 0.321
+semantic: 0.236
+assembly: 0.194
+vnc: 0.187
+other: 0.178
+KVM: 0.003
+
+TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
diff --git a/results/classifier/semantic-bugs/mistranslation/508 b/results/classifier/semantic-bugs/mistranslation/508
new file mode 100644
index 000000000..b05d57a9e
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/508
@@ -0,0 +1,14 @@
+mistranslation: 0.964
+device: 0.838
+instruction: 0.772
+other: 0.598
+network: 0.591
+graphic: 0.501
+semantic: 0.261
+boot: 0.211
+assembly: 0.091
+vnc: 0.078
+socket: 0.066
+KVM: 0.009
+
+x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
diff --git a/results/classifier/semantic-bugs/mistranslation/83 b/results/classifier/semantic-bugs/mistranslation/83
new file mode 100644
index 000000000..ca61d874d
--- /dev/null
+++ b/results/classifier/semantic-bugs/mistranslation/83
@@ -0,0 +1,14 @@
+mistranslation: 0.859
+instruction: 0.857
+device: 0.813
+other: 0.511
+graphic: 0.374
+boot: 0.370
+socket: 0.204
+semantic: 0.165
+vnc: 0.149
+network: 0.095
+assembly: 0.028
+KVM: 0.001
+
+QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit
diff --git a/results/classifier/semantic-bugs/other/1267955 b/results/classifier/semantic-bugs/other/1267955
new file mode 100644
index 000000000..fe1635901
--- /dev/null
+++ b/results/classifier/semantic-bugs/other/1267955
@@ -0,0 +1,187 @@
+other: 0.979
+assembly: 0.959
+device: 0.954
+KVM: 0.953
+vnc: 0.950
+instruction: 0.947
+semantic: 0.945
+graphic: 0.944
+network: 0.942
+mistranslation: 0.913
+socket: 0.912
+boot: 0.895
+
+[i386] Parity Flag Not Set On xor %eax,%eax
+
+Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid
+
+Steps To Reproduce
+
+$ cat > prog.hex << EOF
+
+7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00
+02 00 03 00 01 00 00 00  54 80 04 08 34 00 00 00
+00 00 00 00 00 00 00 00  34 00 20 00 01 00 28 00
+00 00 00 00 01 00 00 00  00 00 00 00 00 80 04 08
+00 80 04 08 76 00 00 00  76 00 00 00 05 00 00 00
+00 10 00 00
+
+31 c0
+9c
+
+b8 04 00 00 00
+bb 01 00 00 00
+89 e1
+ba 04 00 00 00
+cd 80
+
+b8 01 00 00 00
+bb 00 00 00 00
+cd 80
+
+EOF
+
+$ xxd -p -r prog.hex > prog
+$ chmod 700 prog
+
+$ ./prog | hexdump -vC
+00000000  46 02 00 00                                       |F...|
+00000004
+
+$ qemu-i386 ./prog | hexdump -vC
+00000000  42 02 00 00                                       |B...|
+00000004
+
+On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly.
+
+Parity should be set for a zero result.
+
+Signed-off-by: Richard Henderson <email address hidden>
+---
+ target-i386/cc_helper.c | 2 +-
+ target-i386/translate.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c
+index ee04092..05dd12b 100644
+--- a/target-i386/cc_helper.c
++++ b/target-i386/cc_helper.c
+@@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1,
+     case CC_OP_EFLAGS:
+         return src1;
+     case CC_OP_CLR:
+-        return CC_Z;
++        return CC_Z | CC_P;
+ 
+     case CC_OP_MULB:
+         return compute_all_mulb(dst, src1);
+diff --git a/target-i386/translate.c b/target-i386/translate.c
+index b0f2279..34f35e7 100644
+--- a/target-i386/translate.c
++++ b/target-i386/translate.c
+@@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s)
+         return;
+     }
+     if (s->cc_op == CC_OP_CLR) {
+-        tcg_gen_movi_tl(cpu_cc_src, CC_Z);
++        tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P);
+         set_cc_op(s, CC_OP_EFLAGS);
+         return;
+     }
+-- 
+1.8.4.2
+
+
+
+On Fri, Jan 10, 2014 at 12:39:56PM -0800, Richard Henderson wrote:
+> Parity should be set for a zero result.
+> 
+> Signed-off-by: Richard Henderson <email address hidden>
+
+Reviewed-by: Edgar E. Iglesias <email address hidden>
+
+
+> ---
+>  target-i386/cc_helper.c | 2 +-
+>  target-i386/translate.c | 2 +-
+>  2 files changed, 2 insertions(+), 2 deletions(-)
+> 
+> diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c
+> index ee04092..05dd12b 100644
+> --- a/target-i386/cc_helper.c
+> +++ b/target-i386/cc_helper.c
+> @@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1,
+>      case CC_OP_EFLAGS:
+>          return src1;
+>      case CC_OP_CLR:
+> -        return CC_Z;
+> +        return CC_Z | CC_P;
+>  
+>      case CC_OP_MULB:
+>          return compute_all_mulb(dst, src1);
+> diff --git a/target-i386/translate.c b/target-i386/translate.c
+> index b0f2279..34f35e7 100644
+> --- a/target-i386/translate.c
+> +++ b/target-i386/translate.c
+> @@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s)
+>          return;
+>      }
+>      if (s->cc_op == CC_OP_CLR) {
+> -        tcg_gen_movi_tl(cpu_cc_src, CC_Z);
+> +        tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P);
+>          set_cc_op(s, CC_OP_EFLAGS);
+>          return;
+>      }
+> -- 
+> 1.8.4.2
+> 
+> 
+
+
+Quoting Richard Henderson (2014-01-10 14:39:56)
+> Parity should be set for a zero result.
+> 
+> Signed-off-by: Richard Henderson <email address hidden>
+
+ping for 1.7.1
+
+> ---
+>  target-i386/cc_helper.c | 2 +-
+>  target-i386/translate.c | 2 +-
+>  2 files changed, 2 insertions(+), 2 deletions(-)
+> 
+> diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c
+> index ee04092..05dd12b 100644
+> --- a/target-i386/cc_helper.c
+> +++ b/target-i386/cc_helper.c
+> @@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1,
+>      case CC_OP_EFLAGS:
+>          return src1;
+>      case CC_OP_CLR:
+> -        return CC_Z;
+> +        return CC_Z | CC_P;
+> 
+>      case CC_OP_MULB:
+>          return compute_all_mulb(dst, src1);
+> diff --git a/target-i386/translate.c b/target-i386/translate.c
+> index b0f2279..34f35e7 100644
+> --- a/target-i386/translate.c
+> +++ b/target-i386/translate.c
+> @@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s)
+>          return;
+>      }
+>      if (s->cc_op == CC_OP_CLR) {
+> -        tcg_gen_movi_tl(cpu_cc_src, CC_Z);
+> +        tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P);
+>          set_cc_op(s, CC_OP_EFLAGS);
+>          return;
+>      }
+> -- 
+> 1.8.4.2
+
+
+
+Fix had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d2fe51bda8adf33d07c21
+==> Closing
+
diff --git a/results/classifier/semantic-bugs/other/2371 b/results/classifier/semantic-bugs/other/2371
new file mode 100644
index 000000000..2db65ca18
--- /dev/null
+++ b/results/classifier/semantic-bugs/other/2371
@@ -0,0 +1,65 @@
+other: 0.840
+semantic: 0.839
+graphic: 0.831
+mistranslation: 0.816
+vnc: 0.770
+socket: 0.722
+network: 0.699
+instruction: 0.679
+device: 0.671
+assembly: 0.628
+boot: 0.550
+KVM: 0.531
+
+A bug in RISC-V froundnx.h instruction
+Description of problem:
+According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN.
+However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h:
+```
+// target/riscv/fpu_helper.c
+uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1)
+{
+    float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h.
+    frs1 = float16_round_to_int(frs1, &env->fp_status);
+    return nanbox_h(env, frs1);
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
+char o_F5[8];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        printf("%02x ", o_F5[i]);
+    }
+    printf("\n");
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        "lui t5, %hi(i_F6)\n"
+        "addi t5, t5, %lo(i_F6)\n"
+        "fld ft6, 0(t5)\n"
+        ".insn 0x445372d3\n" // froundnx.h ft5, ft6
+        "lui t5, %hi(o_F5)\n"
+        "addi t5, t5, %lo(o_F5)\n"
+        "fsd ft5, 0(t5)\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/other/2372 b/results/classifier/semantic-bugs/other/2372
new file mode 100644
index 000000000..577fd84ae
--- /dev/null
+++ b/results/classifier/semantic-bugs/other/2372
@@ -0,0 +1,122 @@
+other: 0.980
+graphic: 0.975
+semantic: 0.973
+instruction: 0.950
+assembly: 0.946
+device: 0.939
+socket: 0.930
+network: 0.922
+vnc: 0.901
+boot: 0.887
+mistranslation: 0.862
+KVM: 0.808
+
+A bug in AArch64 UMOPA/UMOPS (4-way) instruction
+Description of problem:
+umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element.
+
+However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation:
+```
+// target/arm/tcg/sme_helper.c
+#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \
+static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \
+{                                                                           \
+    uint64_t sum = 0;                                                       \
+    /* Apply P to N as a mask, making the inactive elements 0. */           \
+    n &= expand_pred_h(p);                                                  \
+    sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0);                               \
+    sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16);                             \
+    sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32);                             \
+    sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48);                             \
+    return neg ? a - sum : a + sum;                                         \
+}
+
+DEF_IMOP_64(umopa_d, uint16_t, uint16_t)
+```
+When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication.
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_P1[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_P5[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_Z0[32] = { // Set only the first element as non-zero
+    0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_Z20[32] = { // Set only the first element as non-zero
+    0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_ZA2H[128] = { 0x0, };
+char o_ZA2H[128];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        for (int j = 0; j < 16; j++) {
+            printf("%02x ", o_ZA2H[16*i+j]);
+        }
+        printf("\n");
+    }
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".arch armv9.3-a+sme\n"
+        "smstart\n"
+        "adrp x29, i_P1\n"
+        "add x29, x29, :lo12:i_P1\n"
+        "ldr p1, [x29]\n"
+        "adrp x29, i_P5\n"
+        "add x29, x29, :lo12:i_P5\n"
+        "ldr p5, [x29]\n"
+        "adrp x29, i_Z0\n"
+        "add x29, x29, :lo12:i_Z0\n"
+        "ldr z0, [x29]\n"
+        "adrp x29, i_Z20\n"
+        "add x29, x29, :lo12:i_Z20\n"
+        "ldr z20, [x29]\n"
+        "adrp x29, i_ZA2H\n"
+        "add x29, x29, :lo12:i_ZA2H\n"
+        "mov x15, 0\n"
+        "ld1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "ld1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        ".inst 0xa1f43402\n" // umopa   za2.d, p5/m, p1/m, z0.h, z20.h
+        "adrp x29, o_ZA2H\n"
+        "add x29, x29, :lo12:o_ZA2H\n"
+        "mov x15, 0\n"
+        "st1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "st1d {za2h.d[w15, 0]}, p1, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1d {za2h.d[w15, 1]}, p1, [x29]\n"
+        "smstop\n"
+        ".arch armv8-a\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/other/2374 b/results/classifier/semantic-bugs/other/2374
new file mode 100644
index 000000000..676db53f4
--- /dev/null
+++ b/results/classifier/semantic-bugs/other/2374
@@ -0,0 +1,124 @@
+other: 0.893
+instruction: 0.885
+device: 0.878
+graphic: 0.876
+vnc: 0.873
+semantic: 0.872
+assembly: 0.865
+boot: 0.833
+network: 0.812
+KVM: 0.804
+mistranslation: 0.792
+socket: 0.782
+
+A bug in AArch64 FMOPA/FMOPS (non-widening) instruction
+Description of problem:
+fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated.
+
+However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed:
+```
+// target/arm/tcg/sme_helper.c
+void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn,
+                         void *vpm, void *vst, uint32_t desc)
+{
+...
+    float_status fpst;
+
+    /*
+     * Make a copy of float_status because this operation does not
+     * update the cumulative fp exception status.  It also produces
+     * default nans.
+     */
+    fpst = *(float_status *)vst;
+    set_default_nan_mode(true, &fpst);
+
+...
+                            *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used
+...
+}
+```
+Steps to reproduce:
+1. Write `test.c`.
+```
+#include <stdio.h>
+
+char i_P0[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_P6[4] = { 0xff, 0xff, 0xff, 0xff };
+char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN.
+    0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_Z27[32] = {
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+};
+char i_ZA1H[128] = { 0x0, };
+char o_ZA1H[128];
+
+void __attribute__ ((noinline)) show_state() {
+    for (int i = 0; i < 8; i++) {
+        for (int j = 0; j < 16; j++) {
+            printf("%02x ", o_ZA1H[16*i+j]);
+        }
+        printf("\n");
+    }
+}
+
+void __attribute__ ((noinline)) run() {
+    __asm__ (
+        ".arch armv9.3-a+sme\n"
+        "smstart\n"
+        "adrp x29, i_P0\n"
+        "add x29, x29, :lo12:i_P0\n"
+        "ldr p0, [x29]\n"
+        "adrp x29, i_P6\n"
+        "add x29, x29, :lo12:i_P6\n"
+        "ldr p6, [x29]\n"
+        "adrp x29, i_Z9\n"
+        "add x29, x29, :lo12:i_Z9\n"
+        "ldr z9, [x29]\n"
+        "adrp x29, i_Z27\n"
+        "add x29, x29, :lo12:i_Z27\n"
+        "ldr z27, [x29]\n"
+        "adrp x29, i_ZA1H\n"
+        "add x29, x29, :lo12:i_ZA1H\n"
+        "mov x15, 0\n"
+        "ld1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "ld1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "ld1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        ".inst 0x809bc121\n" // fmopa   za1.s, p0/m, p6/m, z9.s, z27.s
+        "adrp x29, o_ZA1H\n"
+        "add x29, x29, :lo12:o_ZA1H\n"
+        "mov x15, 0\n"
+        "st1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "mov x15, 2\n"
+        "st1w {za1h.s[w15, 0]}, p0, [x29]\n"
+        "add x29, x29, 32\n"
+        "st1w {za1h.s[w15, 1]}, p0, [x29]\n"
+        ".arch armv8-a\n"
+    );
+}
+
+int main(int argc, char **argv) {
+    run();
+    show_state();
+    return 0;
+}
+```
+2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`.
+3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`.
+4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed.
+Additional information:
+
diff --git a/results/classifier/semantic-bugs/semantic/1156313 b/results/classifier/semantic-bugs/semantic/1156313
new file mode 100644
index 000000000..54d2d0f95
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1156313
@@ -0,0 +1,128 @@
+semantic: 0.869
+mistranslation: 0.841
+assembly: 0.789
+device: 0.777
+instruction: 0.707
+other: 0.705
+vnc: 0.702
+graphic: 0.657
+socket: 0.605
+boot: 0.576
+network: 0.533
+KVM: 0.518
+
+X86-64 flags handling broken
+
+The current qemu sources cause improper handling of flags on x86-64.
+This bug seems to have shown up a few weeks ago.
+
+A plain install of Debian GNU/Linux makes user processes catch
+spurious signals.  The kernel seems to run stably, though.
+
+The ADX feature works very poorly.  It might be related; at least it
+allows for reproducibly provoking invalid behaviour.
+
+Here is a test case:
+
+================================================================
+qemumain.c
+#include <stdio.h>
+long adx();
+int
+main ()
+{
+  printf ("%lx\n", adx (0xffbeef, 17));
+  return 0;
+}
+================================================================
+qemuadx.s:
+        .globl  adx
+adx:    xor     %rax, %rax
+1:      dec     %rdi
+        jnz     1b
+        .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adox  %rax, %rax
+        .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adcx  %rax, %rax
+        ret
+================================================================
+
+Compile and execute:
+$ gcc -m64 qemumain.c qemuadx.s
+$ a.out
+ffffff8000378cd8
+
+Expected output is simply "0".  The garbage value varies between qemu
+compiles and guest systems.
+
+Note that one needs a recent GNU assembler in order to handle adox and
+adcx.  For convenience I have supplied them as byte sequences.
+
+Exaplanation and feeble analysis:
+
+The 0xffbeef argument is a loop count.  It is necessary to loop for a
+while in order to trigger this bug.  If the loop count is decreased,
+the bug will seen intermittently; the lower the count, the less
+frequent the invalid behaviour.
+
+It seems like a reasonable assumption that this bug is related to
+flags handling at context switch.  Presumably, qemu keeps flags state
+in some internal format, then recomputes then when needing to form the
+eflags register, as needed for example for context switching.
+
+I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT,
+but I strongly suspect that to be impossible.  I use
+qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version
+6.0.6) .
+
+The bug happens also with the guest FreeBSD x86_64 version 9.1.  (The
+iteration count for triggering the problem 50% of the runs is not the
+same when using the kernel Linux and FreeBSD's kernel, presumably due
+to different ticks.)
+
+The bug happens much more frequently for a loaded system; in fact, the
+loop count can be radically decreased if two instances of the trigger
+program are run in parallel.
+
+Richard Henderson <email address hidden> writes:
+
+  Patch at http://patchwork.ozlabs.org/patch/229139/
+  
+Thanks.  I can confirm that this fixes the bug triggered by my test case
+(and yours).  However, the instability of Debian GNU/Linux x86_64 has
+not improved.
+
+The exact same Debian version (debian "testing") updated at the same
+time runs well on hardware.
+
+My qemu Debian system now got messed up, since I attempted an upgrade in
+the buggy qemu, which segfaulted several times during the upgrade.  I
+need to reinstall, and then rely on -snapshot.
+
+There is a problem with denorms which is reproducible, but whether that
+is a qemu bug, and whether it can actually cause the observed
+instability, is questionable.  Here is a testcase for that problem:
+
+
+
+
+It should terminate.  The observed buggy behaviour is that it hangs.
+
+The instability problem can be observed at gmplib.org/devel/tm-date.html.
+hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx.
+
+Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org).
+It is neither instable nor does it run the denorms testcase poorly.
+
+I fully realise this is a hopeless bug report, but I am sure you can
+reproduce it, since it is far from GMP specific.  After all apt-get
+update; apt-get upgrade triggered it.  Debugging it will be a nightmare.
+
+Qemu version: main git repo from less than a week ago + Richard ADX
+patch.
+
+-- 
+Torbjörn
+
+
+It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug.
+
+
diff --git a/results/classifier/semantic-bugs/semantic/1370 b/results/classifier/semantic-bugs/semantic/1370
new file mode 100644
index 000000000..c7f125abf
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1370
@@ -0,0 +1,26 @@
+semantic: 0.986
+instruction: 0.949
+graphic: 0.878
+assembly: 0.842
+device: 0.806
+socket: 0.681
+vnc: 0.658
+network: 0.606
+boot: 0.546
+mistranslation: 0.502
+other: 0.474
+KVM: 0.210
+
+x86 BLSI and BLSR semantic bug
+Description of problem:
+The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("blsi rax, rbx");
+}
+```
+2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1371 b/results/classifier/semantic-bugs/semantic/1371
new file mode 100644
index 000000000..16aca0c8f
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1371
@@ -0,0 +1,32 @@
+semantic: 0.995
+instruction: 0.970
+assembly: 0.852
+graphic: 0.824
+device: 0.665
+mistranslation: 0.491
+boot: 0.468
+vnc: 0.465
+socket: 0.452
+network: 0.307
+other: 0.217
+KVM: 0.064
+
+x86 BLSMSK semantic bug
+Description of problem:
+The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - CF = 0
+    - QEMU
+        - CF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1372 b/results/classifier/semantic-bugs/semantic/1372
new file mode 100644
index 000000000..a5a86bb81
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1372
@@ -0,0 +1,33 @@
+semantic: 0.995
+instruction: 0.963
+graphic: 0.860
+device: 0.736
+assembly: 0.728
+mistranslation: 0.574
+vnc: 0.420
+boot: 0.411
+socket: 0.263
+network: 0.171
+other: 0.159
+KVM: 0.083
+
+x86 BEXTR semantic bug
+Description of problem:
+The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x17b3693f77fb6e9");
+    asm("mov rbx, 0x8f635a775ad3b9b4");
+    asm("mov rcx, 0xb717b75da9983018");
+    asm("bextr eax, ebx, ecx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x5a
+    - QEMU
+        - RAX = 0x635a775a
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1373 b/results/classifier/semantic-bugs/semantic/1373
new file mode 100644
index 000000000..d4cf2ba67
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1373
@@ -0,0 +1,33 @@
+semantic: 0.996
+assembly: 0.951
+instruction: 0.948
+graphic: 0.898
+device: 0.784
+vnc: 0.746
+mistranslation: 0.642
+boot: 0.505
+socket: 0.502
+network: 0.373
+other: 0.248
+KVM: 0.113
+
+x86 ADOX and ADCX semantic bug
+Description of problem:
+The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("push 512; popfq;");
+    asm("mov rax, 0xffffffff84fdbf24");
+    asm("mov rbx, 0xb197d26043bec15d");
+    asm("adox eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
+    - CPU
+        - OF = 0
+    - QEMU
+        - OF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1374 b/results/classifier/semantic-bugs/semantic/1374
new file mode 100644
index 000000000..0db6a0198
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1374
@@ -0,0 +1,35 @@
+semantic: 0.993
+instruction: 0.952
+graphic: 0.807
+device: 0.700
+assembly: 0.661
+boot: 0.382
+vnc: 0.341
+socket: 0.314
+network: 0.272
+mistranslation: 0.272
+other: 0.093
+KVM: 0.044
+
+x86 BZHI semantic bug
+Description of problem:
+The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0xb1aa9da2fe33fe3");
+    asm("mov rbx, 0x80000000ffffffff");
+    asm("mov rcx, 0xf3fce8829b99a5c6");
+    asm("bzhi rax, rbx, rcx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x0x80000000ffffffff
+        - SF = 1
+    - QEMU
+        - RAX = 0xffffffff
+        - SF = 0
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1375 b/results/classifier/semantic-bugs/semantic/1375
new file mode 100644
index 000000000..3d7746382
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1375
@@ -0,0 +1,32 @@
+semantic: 0.988
+instruction: 0.945
+graphic: 0.792
+device: 0.739
+other: 0.687
+assembly: 0.675
+vnc: 0.520
+network: 0.458
+boot: 0.413
+socket: 0.407
+mistranslation: 0.269
+KVM: 0.247
+
+x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
+Description of problem:
+The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
+    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
+    asm("addsubps xmm1, xmm2");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
+    - CPU
+        - xmm1[3] = 0xffffffff
+    - QEMU
+        - xmm1[3] = 0x7fffffff
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1428352 b/results/classifier/semantic-bugs/semantic/1428352
new file mode 100644
index 000000000..b63b8cedc
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1428352
@@ -0,0 +1,63 @@
+semantic: 0.788
+other: 0.739
+graphic: 0.673
+mistranslation: 0.665
+instruction: 0.659
+assembly: 0.653
+device: 0.631
+vnc: 0.613
+KVM: 0.595
+network: 0.538
+boot: 0.531
+socket: 0.491
+
+SYSRET instruction incorrectly implemented
+
+The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic:
+
+SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *)
+
+Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here:
+
+http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html
+
+[...]
+        SS(SEL) = IA32_STAR[63:48] + 8;
+        SS(PL) = 0x3;
+[...]
+
+In other words, the value of the %ss register is supposed to be loaded from  bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call.
+
+However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this:
+
+        cpu_x86_load_seg_cache(env, R_SS, selector + 8,
+                               0, 0xffffffff,
+                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
+                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
+                               DESC_W_MASK | DESC_A_MASK);
+
+It should look like this:
+
+        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
+                               0, 0xffffffff,
+                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
+                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
+                               DESC_W_MASK | DESC_A_MASK);
+
+The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss).
+
+The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.)
+
+This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :)
+
+Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM.
+
+The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware.
+
+- Bill (<email address hidden>)
+
+
+
+If I've got that right, this has been fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ac57622985220de0
+
diff --git a/results/classifier/semantic-bugs/semantic/1809546 b/results/classifier/semantic-bugs/semantic/1809546
new file mode 100644
index 000000000..dfeb2f575
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1809546
@@ -0,0 +1,90 @@
+semantic: 0.913
+instruction: 0.876
+device: 0.860
+other: 0.855
+boot: 0.852
+assembly: 0.850
+graphic: 0.848
+network: 0.811
+mistranslation: 0.754
+vnc: 0.735
+socket: 0.612
+KVM: 0.608
+
+Writing a byte to a pl011 SFR overwrites the whole SFR
+
+The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master.
+
+I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application.
+
+Given:
+
+pl011_addr: .word 0x10009000
+
+The following snippet will be problematic:
+
+     ldr r3, pl011_addr
+     ldrb r2, [r3, #0x38]        // IMSC
+     mov r2, #0
+     orr r2, r2, #0x10           // R2 == 0x10
+     strb r2, [r3, #0x38]        // Whole word reads correctly after this
+     ldrb r2, [r3, #0x39]
+     mov r2, #0
+     strb r2, [r3, #0x39]        // Problem here! Overwrites offset 0x38 as well
+
+After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor:
+
+(qemu) xp 0x10009038
+0000000010009038: 0x00000010
+
+After the second strb instruction, the write to 0x10009039 clears the entire word:
+
+(qemu) xp 0x10009038
+0000000010009038: 0x00000000
+
+QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000:
+
+qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio
+
+Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write:
+
+    ldr r3, pl011_addr
+    mov r2, #0x10
+    str r2, [r3, #0x38]
+
+Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code.
+
+I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR.
+
+
+
+Adding the link script.
+
+Yes, our PL011 implementation assumes that you only ever access the 32-bit registers with full width 32-bit word reads and writes. Don't try to do byte accesses to them. The PL011 data sheet doesn't specifically say that partial-width accesses to registers are permitted, so I think that trying to access offset 0x39 falls under the general note in section 3.1 that attempting to access reserved or unused address locations can result in unpredictable behaviour.
+
+You need to make sure you write your C code in a manner which enforces that accesses to device registers are done as single 32-bit accesses, and the compiler does not silently break them down into multiple reads and writes, or you will be in for a lot of pain trying to figure out what is going on if the compiler ever does it with registers that are write-to-clear or similar behaviour. Linux, for instance, does this by having readl() and writel() functions that end up doing inline asm of ldr/str instructions.
+
+
+Thanks for the response.
+
+I don't think section 3.1 applies to 8-bit accesses. That is specifically about reserved locations, and neither offset 0x38 nor 0x39 are reserved, so I think it's a matter of whether 32-bit access is required or not.
+
+From what I usually see in ARM documentation, 32-bit access is explicitly mentioned when required. For the PL011, it's mentioned for the UARTPeriphID_n registers, for instance. In many other cases access size depends on the implementation and the corresponding memory mapping of that implementation.
+
+I understand that *in practice* you should ensure single-access writes unless doing otherwise is explicitly allowed. However, in cases like the PL011 it seems ambiguous whether that is actually required, so it seems like the best choice would be to explicitly document it for the QEMU implementation. That would save some guesswork.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/semantic-bugs/semantic/1923197 b/results/classifier/semantic-bugs/semantic/1923197
new file mode 100644
index 000000000..06e794798
--- /dev/null
+++ b/results/classifier/semantic-bugs/semantic/1923197
@@ -0,0 +1,149 @@
+semantic: 0.907
+mistranslation: 0.879
+other: 0.869
+assembly: 0.855
+instruction: 0.854
+socket: 0.832
+device: 0.813
+graphic: 0.805
+KVM: 0.794
+vnc: 0.737
+boot: 0.724
+network: 0.710
+
+RISC-V priviledged instruction error
+
+Hello when performing an MRET with MPP set to something else than 0b11 in MSTATUS, 'Invalid Instruction' exception will be triggered. The problem appeared in code after version 5.2.0.
+
+<pre>
+  # setup interrupt handling for monitor mode
+  la t0, entry_loop
+  la t1, entry_trap
+  li t2, 0x888
+  li t3, 0x1880 # MPP in MSTATUS selects to which mode to return & MPIE selects if to enable interrupts after MRET
+  csrw mepc, t0
+  csrw mtvec, t1
+  csrs mie, t2
+  csrs mstatus, t3
+
+  # if supervisor mode not supported, then loop forever
+  csrr t0, misa
+  li t1, 0x40000
+  and t2, t1, t0
+  beqz t2, 1f
+
+  # setup interrupt i& exception delegation for supervisor mode
+  li t0, 0xc0000000 # 3 GiB (entry address of supervisor)
+  li t1, 0x1000
+  #li t2, 0x300 # bit 8 & 9 is for ecall from user & supervisor mode
+  #li t3, 0x222
+  csrw mepc, t0
+  csrc mstatus, t1
+  #csrs medeleg, t2
+  #csrs mideleg, t3
+
+  # pass mhartid as first parameter to supervisor
+  csrr a0, mhartid
+
+1:
+  mret
+</pre>
+
+I'm guessing that this is a bug in your guest as it hasn't configured PMP regions.
+
+From the RISC-V spec:
+
+"
+If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an
+S-mode or U-mode access, but at least one PMP entry is implemented, the access fails.
+"
+
+Confusingly implemented here means implemented in hardware, not just configured.
+
+You can check this by reverting this QEMU commit:
+
+commit d102f19a2085ac931cb998e6153b73248cca49f1
+Author: Atish Patra <email address hidden>
+Date:   Wed Dec 23 11:25:53 2020 -0800
+
+    target/riscv/pmp: Raise exception if no PMP entry is configured
+    
+    As per the privilege specification, any access from S/U mode should fail
+    if no pmp region is configured.
+    
+    Signed-off-by: Atish Patra <email address hidden>
+    Reviewed-by: Alistair Francis <email address hidden>
+    Message-id: <email address hidden>
+    Signed-off-by: Alistair Francis <email address hidden>
+
+
+Hello Francis,
+
+I'll configure PMP than do the test again. Sorry I hadn't understood what
+changed between version 5.2 and 6.0-rc2, since my code worked before.
+
+Best regards,
+Teodori Serge
+
+On Thu, 15 Apr 2021, 06:15 Alistair Francis, <email address hidden>
+wrote:
+
+> I'm guessing that this is a bug in your guest as it hasn't configured
+> PMP regions.
+>
+> >From the RISC-V spec:
+>
+> "
+> If no PMP entry matches an M-mode access, the access succeeds. If no PMP
+> entry matches an
+> S-mode or U-mode access, but at least one PMP entry is implemented, the
+> access fails.
+> "
+>
+> Confusingly implemented here means implemented in hardware, not just
+> configured.
+>
+> ** Changed in: qemu
+>        Status: Confirmed => Invalid
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1923197
+>
+> Title:
+>   RISC-V priviledged instruction error
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
+>
+
+
+We fixed a bug to make QEMU act more like hardware, which now means that PMP must be configured in M-mode.
+
+Hello Francis,
+
+Yes thank you. I added code to setup a basic PMP and it works now. Thank
+you and best regards,
+
+Teodori Serge
+
+On Sun, 18 Apr 2021, 05:55 Alistair Francis, <email address hidden>
+wrote:
+
+> We fixed a bug to make QEMU act more like hardware, which now means that
+> PMP must be configured in M-mode.
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1923197
+>
+> Title:
+>   RISC-V priviledged instruction error
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
+>
+
+
diff --git a/results/classifier/semantic-bugs/vnc/1785734 b/results/classifier/semantic-bugs/vnc/1785734
new file mode 100644
index 000000000..127f85c5e
--- /dev/null
+++ b/results/classifier/semantic-bugs/vnc/1785734
@@ -0,0 +1,129 @@
+vnc: 0.771
+KVM: 0.765
+mistranslation: 0.764
+other: 0.750
+device: 0.674
+graphic: 0.667
+instruction: 0.658
+assembly: 0.629
+socket: 0.621
+semantic: 0.612
+boot: 0.579
+network: 0.578
+
+movdqu partial write at page boundary
+
+In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example.
+
+Tested on the qemu-3.0.0-rc1 release.
+
+
+% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out
+*(0x70000ff8+ 0) = aa
+*(0x70000ff8+ 1) = aa
+*(0x70000ff8+ 2) = aa
+*(0x70000ff8+ 3) = aa
+*(0x70000ff8+ 4) = aa
+*(0x70000ff8+ 5) = aa
+*(0x70000ff8+ 6) = aa
+*(0x70000ff8+ 7) = aa
+*(0x70000ff8+ 8) = 55
+*(0x70000ff8+ 9) = 55
+*(0x70000ff8+10) = 55
+*(0x70000ff8+11) = 55
+*(0x70000ff8+12) = 55
+*(0x70000ff8+13) = 55
+*(0x70000ff8+14) = 55
+*(0x70000ff8+15) = 55
+page fault: addr=0x70001000 err=0x7
+*(0x70000ff8+ 0) = aa
+*(0x70000ff8+ 1) = aa
+*(0x70000ff8+ 2) = aa
+*(0x70000ff8+ 3) = aa
+*(0x70000ff8+ 4) = aa
+*(0x70000ff8+ 5) = aa
+*(0x70000ff8+ 6) = aa
+*(0x70000ff8+ 7) = aa
+*(0x70000ff8+ 8) = 55
+*(0x70000ff8+ 9) = 55
+*(0x70000ff8+10) = 55
+*(0x70000ff8+11) = 55
+*(0x70000ff8+12) = 55
+*(0x70000ff8+13) = 55
+*(0x70000ff8+14) = 55
+*(0x70000ff8+15) = 55
+
+*(0x70000ff8+ 0) = aa
+*(0x70000ff8+ 1) = aa
+*(0x70000ff8+ 2) = aa
+*(0x70000ff8+ 3) = aa
+*(0x70000ff8+ 4) = aa
+*(0x70000ff8+ 5) = aa
+*(0x70000ff8+ 6) = aa
+*(0x70000ff8+ 7) = aa
+*(0x70000ff8+ 8) = 55
+*(0x70000ff8+ 9) = 55
+*(0x70000ff8+10) = 55
+*(0x70000ff8+11) = 55
+*(0x70000ff8+12) = 55
+*(0x70000ff8+13) = 55
+*(0x70000ff8+14) = 55
+*(0x70000ff8+15) = 55
+page fault: addr=0x70001000 err=0x6
+*(0x70000ff8+ 0) = 77
+*(0x70000ff8+ 1) = 66
+*(0x70000ff8+ 2) = 55
+*(0x70000ff8+ 3) = 44
+*(0x70000ff8+ 4) = 33
+*(0x70000ff8+ 5) = 22
+*(0x70000ff8+ 6) = 11
+*(0x70000ff8+ 7) = 0
+*(0x70000ff8+ 8) = 55
+*(0x70000ff8+ 9) = 55
+*(0x70000ff8+10) = 55
+*(0x70000ff8+11) = 55
+*(0x70000ff8+12) = 55
+*(0x70000ff8+13) = 55
+*(0x70000ff8+14) = 55
+*(0x70000ff8+15) = 55
+
+
+
+This is a part of a class of related problems for qemu linux-user, in that any non-atomic store is not validated before initiating a partial write.
+
+For instance, qemu-x86_64, built for arm32, would show this same partial store problem for any 64-bit write crossing a page boundary because we are forced by the limits of the host to split the store into two 32-bit pieces.
+
+While we could probably fix this specific case fairly easily, because it is implemented with an external helper in the first place, we would need some new infrastructure to handle the more general problem.  Exactly what form that should take would need some thought and discussion.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
author	Christian Krinitsin <mail@krinitsin.com>	2025-06-12 09:56:59 +0200
committer	Christian Krinitsin <mail@krinitsin.com>	2025-06-12 09:56:59 +0200
commit	b89a938452613061c0f1f23e710281cf5c83cb29 (patch)
tree	d5faecfd167e088848cad894f8dc9cfef3352e3b /results/classifier
parent	7b681b9f9eedaad2f081ae11a32f459f5a1312ff (diff)
download	qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.tar.gz qemu-analysis-b89a938452613061c0f1f23e710281cf5c83cb29.zip