1 files changed, 51 insertions, 0 deletions
diff --git a/results/classifier/118/none/1888165 b/results/classifier/118/none/1888165
new file mode 100644
index 000000000..2d3a67984
--- /dev/null
+++ b/results/classifier/118/none/1888165
@@ -0,0 +1,51 @@
+virtual: 0.596
+device: 0.594
+ppc: 0.473
+graphic: 0.445
+architecture: 0.441
+semantic: 0.425
+x86: 0.417
+network: 0.402
+vnc: 0.336
+debug: 0.319
+mistranslation: 0.311
+performance: 0.281
+socket: 0.247
+files: 0.240
+kernel: 0.220
+permissions: 0.206
+user-level: 0.203
+boot: 0.185
+arm: 0.184
+register: 0.168
+TCG: 0.122
+PID: 0.118
+risc-v: 0.116
+VMM: 0.110
+peripherals: 0.110
+hypervisor: 0.095
+assembly: 0.089
+KVM: 0.051
+i386: 0.020
+
+loopz/loopnz clearing previous instruction's modified flags on cx -> 0
+
+If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction.
+
+After executing a sequence like this in qemu:
+
+	mov bx,1
+	mov cx,1
+	dec bx    ; sets Z bit in flags
+A:	loopnz A  ; should not modify flags
+
+Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting.
+
+Version 5.1.0-rc0, x86-64 host.
+
+
+
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3cb3a7720b01830abd5
+