1 files changed, 65 insertions, 0 deletions
diff --git a/results/classifier/118/arm/1836192 b/results/classifier/118/arm/1836192
new file mode 100644
index 000000000..b26ff5017
--- /dev/null
+++ b/results/classifier/118/arm/1836192
@@ -0,0 +1,65 @@
+arm: 0.821
+ppc: 0.798
+device: 0.784
+architecture: 0.784
+debug: 0.773
+performance: 0.771
+files: 0.763
+user-level: 0.734
+PID: 0.734
+register: 0.704
+boot: 0.695
+semantic: 0.685
+network: 0.682
+risc-v: 0.678
+hypervisor: 0.651
+permissions: 0.651
+kernel: 0.641
+virtual: 0.639
+vnc: 0.638
+graphic: 0.634
+mistranslation: 0.614
+VMM: 0.614
+peripherals: 0.613
+TCG: 0.597
+socket: 0.593
+x86: 0.591
+assembly: 0.551
+KVM: 0.524
+i386: 0.518
+
+Regressions on arm926 target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date: Fri Jun 21 15:40:50 2019 +0100
+
+even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
+I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926.
+
+I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test.
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabi
+--with-cpu arm10tdmi
+--with-fpu vfp
+
+Thanks
+
+
+
+We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support.
+
+
+We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support.
+
+
+I confirm this patch fixes the problem I reported. Thanks!
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb7cef8b32033f6284a47d797
+