[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1233225] Re: mips/mipsel linux user float division pro
From: |
Petar Jovanovic |
Subject: |
[Qemu-devel] [Bug 1233225] Re: mips/mipsel linux user float division problem |
Date: |
Tue, 08 Oct 2013 00:21:07 -0000 |
This is a known issue.
There was a fix proposal by Thomas Schwinge back in June
http://patchwork.ozlabs.org/patch/250161/
but he has not updated the patch per suggestion ever since, though the patch
as is was much closer to correct behaviour than what it is now in the source.
If anyone is in hurry, he/she can pick up that change.
--
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