Regressions on arm926 target with some GCC tests
Bug #1836192 reported by
Christophe Lyon
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Hi,
After trying qemu master:
commit 474f3938d79ab36
Merge: 68d7ff0 14f5d87
Author: Peter Maydell <email address hidden>
Date: Fri Jun 21 15:40:50 2019 +0100
even with the fix for https:/
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-
--with-cpu arm10tdmi
--with-fpu vfp
Thanks
Changed in qemu: | |
status: | New → In Progress |
Changed in qemu: | |
status: | In Progress → Fix Committed |
To post a comment you must log in.
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.