architecture: 0.890
graphic: 0.881
vnc: 0.879
arm: 0.807
performance: 0.678
device: 0.639
risc-v: 0.632
semantic: 0.611
socket: 0.441
VMM: 0.436
boot: 0.416
TCG: 0.413
PID: 0.407
ppc: 0.398
permissions: 0.392
network: 0.348
virtual: 0.335
files: 0.310
mistranslation: 0.274
debug: 0.256
user-level: 0.241
x86: 0.177
i386: 0.155
register: 0.117
kernel: 0.111
peripherals: 0.097
assembly: 0.094
KVM: 0.077
hypervisor: 0.045
--------------------
arm: 0.999
user-level: 0.840
debug: 0.124
virtual: 0.056
TCG: 0.043
performance: 0.030
files: 0.028
register: 0.022
network: 0.019
kernel: 0.011
VMM: 0.007
hypervisor: 0.007
device: 0.006
peripherals: 0.006
PID: 0.006
socket: 0.005
semantic: 0.004
vnc: 0.003
assembly: 0.003
architecture: 0.003
permissions: 0.002
graphic: 0.002
boot: 0.001
risc-v: 0.001
mistranslation: 0.000
ppc: 0.000
KVM: 0.000
x86: 0.000
i386: 0.000

ARM/Neon: vcvt rounding error

Hello,

While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression.

The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t.
The expected result is 125, but we get 126 instead.

Maybe it's just a matter of default rounding mode?

Hi Christophe -- we think that commit bd49e6027cbc207c, now in master, should have fixed this bug. Could you retry your testcase with a QEMU build including that fix?


I updated my QEMU git tree such that it includes commit bd49e6027cbc207c, and the test now passes.

Thanks for the prompt fix!