I can confirm that something is strange with MIPS Linux user emulation, but get a different result (which is also wrong):
# Your test code is in file divtest.c. $ mipsel-linux-gnu-gcc-4.7 -g -static divtest.c $ mipsel-linux-user/qemu-mipsel a.out 0.000000 Some more tests: printf("%f\n", a * 1.0); // 0.000000 = bad printf("%f\n", (double)a); // 0.000000 = bad printf("%f\n", 1.0); // 1.000000 = good Test environment: * latest QEMU sources + default configure & make on x86_64 Debian squeeze host * gcc-4.7-mipsel-linux-gnu 4.7.2-5 amd64 GNU C compiler ** Changed in: qemu Status: New => Confirmed -- 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