On 2 October 2013 14:22, Stefan Weil <s...@weilnetz.de> wrote: > The original bug report said that it runs in QEMU system emulation > (which I did not test because of lack of time). As system emulation > uses the same cpu, it should be fine.
...that's what prompted me to ask, actually -- system emulation will pick a CPU based on whichever board you're emulating, which is quite likely to be a different one from the default picked by linux-user. The original bug report doesn't seem to say which board they used for system emulation so I don't know which CPU it would be using. -- PMM -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1233225 Title: mips/mipsel linux user float division problem Status in QEMU: Confirmed Bug description: Hi, I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program: #include <stdio.h> int main(int argc, char **argv) { int a = 1; double d = a/2.0; printf("%f\n", d); return 0; } Instead of printing 0.5, it will print 2.0 if executed in qemu user mode. $ mipsel-linux-gnu-gcc mipstest.c $ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out 2.0 Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode. Can anybody else reproduce this problem? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1233225/+subscriptions
