https://git.qemu.org/?p=qemu.git;a=commitdiff;h=21ba856499f9c0ccdc
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
Patch now merged to master and will be in QEMU 4.1.
** Changed in: qemu
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
floating-point
The patch mentioned in #15 fixes the issue:
- The test programs test-cbrt ... test-truncf1 now all succeed.
- The test program from comment #6, run with qemu-alpha, prints
680e8000, i.e. bit 59 is set.
Thanks Richard!!
--
You received this bug notification because you are a member of
There is quite a bit missing for proper user-level emulation.
Please try
https://patchwork.ozlabs.org/patch/1091847/
** Changed in: qemu
Assignee: (unassigned) => Richard Henderson (rth)
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because
There seems to be more confusion of the sort. This fixes it for me:
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10226,7 +10226,7 @@ static abi_long do_syscall1(void *cpu_env, int num,
abi_long arg1,
return -TARGET_EFAULT;
}
The problem is still reproducible with QEMU 4.0.0:
- The test programs test-cbrt ... test-truncf1 crash or abort as described.
- The test program from comment #6, run with qemu-alpha, prints
600e8000, i.e. bit 59 is unset.
--
You received this bug notification because you are a member
Commit https://git.qemu.org/?p=qemu.git;a=commitdiff;h=29eb528078683
claims that this has been fixed. Is the problem still reproducible with
QEMU 4.0?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 1/7/19 8:20 AM, Bruno Haible wrote:
> No, it is not fixed: even with this patch the program that fetches the
> fpcr still prints 600e8000, and the various program crashes
> still occur.
Are you sure you rebuilt properly? The fpcr prints 680e8000 here.
r~
No, it is not fixed: even with this patch the program that fetches the
fpcr still prints 600e8000, and the various program crashes
still occur.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Should be fixed by:
http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg00726.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
floating-point operation bugs in qemu-alpha
The fpcr value seen in a process running in a VM comes from the Linux
kernel, file linux/arch/alpha/kernel/process.c, function flush_thread():
/* Arrange for each exec'ed process to start off with a clean slate
with respect to the FPU. This is all exceptions disabled. */
https://download.majix.org/dec/alpha_arch_ref.pdf
The bits are defined in 4.7.8 Floating-Point Control Register (FPCR).
59/58 zero is chopped rounding. This does not seem like a good default.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
Under qemu-system-alpha I get 680e8000 as well.
Under qemu-alpha (versions 2.8.1, 2.9.0, 2.10.0, 2.11.0, 2.12.0, 3.1.0)
I get 600e8000, i.e. bit 59 is unset.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Run this:
#include
#include
double get_fpcr()
{
double x;
asm ("mf_fpcr %0": "=f" (x));
return x;
}
int main()
{
double fpcr = get_fpcr();
unsigned long l;
memcpy(, , 8);
printf("%016lx\n", l);
return 0;
}
Under qemu-system-alpha I get 680e8000.
--
Most likely some bits are initialized differently in the FPCR.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
floating-point operation bugs in qemu-alpha
Status in QEMU:
New
Bug
> You should try building with -mieee.
When I build with
../configure CFLAGS="-mieee -O2 -g" CPPFLAGS=-Wall LDFLAGS="-static -lieee"
I observe the exact same behaviour: Only 4 tests fail in a VM executed with
qemu-system-alpha, whereas the same test failures (from test-cbrt to
test-truncf1) are
This is likely expected/correct behavior. You should try building with
-mieee.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
floating-point operation bugs in qemu-alpha
Status in
The behaviour in qemu-2.11 is the same as in qemu-2.9.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835
Title:
floating-point operation bugs in qemu-alpha
Status in QEMU:
New
Bug
18 matches
Mail list logo
