add 18th iteration of classifier

1 files changed, 42 insertions, 0 deletions

diff --git a/results/classifier/118/risc-v/1820686 b/results/classifier/118/risc-v/1820686
new file mode 100644
index 00000000..a264e8c0
--- /dev/null
+++ b/results/classifier/118/risc-v/1820686
@@ -0,0 +1,42 @@
+risc-v: 0.992
+device: 0.824
+network: 0.809
+socket: 0.724
+virtual: 0.719
+architecture: 0.717
+semantic: 0.691
+vnc: 0.683
+mistranslation: 0.678
+kernel: 0.658
+performance: 0.598
+graphic: 0.598
+x86: 0.595
+i386: 0.580
+debug: 0.553
+ppc: 0.532
+boot: 0.498
+VMM: 0.495
+peripherals: 0.494
+arm: 0.490
+hypervisor: 0.467
+register: 0.457
+files: 0.428
+TCG: 0.378
+PID: 0.366
+KVM: 0.321
+assembly: 0.305
+user-level: 0.296
+permissions: 0.246
+
+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.
+