other: 0.793
device: 0.784
debug: 0.773
performance: 0.771
files: 0.763
PID: 0.734
boot: 0.695
semantic: 0.685
network: 0.682
permissions: 0.651
vnc: 0.638
graphic: 0.634
socket: 0.593
KVM: 0.524

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