All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero
       [not found] <153726785322.19300.9182114718255539260.malonedeb@wampee.canonical.com>
@ 2018-10-10 14:23 ` Emilio G. Cota
  2018-10-10 14:45 ` Koutheir Attouchi
  2018-12-12  9:17 ` Thomas Huth
  2 siblings, 0 replies; 3+ messages in thread
From: Emilio G. Cota @ 2018-10-10 14:23 UTC (permalink / raw)
  To: qemu-devel

** Changed in: qemu
       Status: Confirmed => 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/1793119

Title:
  Wrong floating-point emulation on AArch64 with FPCR set to zero

Status in QEMU:
  Fix Committed

Bug description:
  On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant
  mode), floating-point emulation does not produce the same results as
  real hardware (e.g., Raspberry Pi 3 with AArch64 Linux).

  I attached a sample that reproduces the issue. It divides `x` by `y`
  and puts the result in `r`. The expected result of the operation is
  `q`.

  Output on real hardware:
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` equals `q`.

  Output on qemu 3.0.0 (Linux user-mode emulation):
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` is not equal to `q`.

  Also notice that, using another proprietary operating system, the same
  issue arises between a real board and QEMU. This might be an issue in
  emulation of the AArch64 instruction "fdiv".

  Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1
  sample1.c

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1793119/+subscriptions

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero
       [not found] <153726785322.19300.9182114718255539260.malonedeb@wampee.canonical.com>
  2018-10-10 14:23 ` [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero Emilio G. Cota
@ 2018-10-10 14:45 ` Koutheir Attouchi
  2018-12-12  9:17 ` Thomas Huth
  2 siblings, 0 replies; 3+ messages in thread
From: Koutheir Attouchi @ 2018-10-10 14:45 UTC (permalink / raw)
  To: qemu-devel

Thanks a lot :-)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1793119

Title:
  Wrong floating-point emulation on AArch64 with FPCR set to zero

Status in QEMU:
  Fix Committed

Bug description:
  On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant
  mode), floating-point emulation does not produce the same results as
  real hardware (e.g., Raspberry Pi 3 with AArch64 Linux).

  I attached a sample that reproduces the issue. It divides `x` by `y`
  and puts the result in `r`. The expected result of the operation is
  `q`.

  Output on real hardware:
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` equals `q`.

  Output on qemu 3.0.0 (Linux user-mode emulation):
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` is not equal to `q`.

  Also notice that, using another proprietary operating system, the same
  issue arises between a real board and QEMU. This might be an issue in
  emulation of the AArch64 instruction "fdiv".

  Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1
  sample1.c

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1793119/+subscriptions

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero
       [not found] <153726785322.19300.9182114718255539260.malonedeb@wampee.canonical.com>
  2018-10-10 14:23 ` [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero Emilio G. Cota
  2018-10-10 14:45 ` Koutheir Attouchi
@ 2018-12-12  9:17 ` Thomas Huth
  2 siblings, 0 replies; 3+ messages in thread
From: Thomas Huth @ 2018-12-12  9:17 UTC (permalink / raw)
  To: qemu-devel

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5dfbc9e4903c0121140f2

** 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/1793119

Title:
  Wrong floating-point emulation on AArch64 with FPCR set to zero

Status in QEMU:
  Fix Released

Bug description:
  On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant
  mode), floating-point emulation does not produce the same results as
  real hardware (e.g., Raspberry Pi 3 with AArch64 Linux).

  I attached a sample that reproduces the issue. It divides `x` by `y`
  and puts the result in `r`. The expected result of the operation is
  `q`.

  Output on real hardware:
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` equals `q`.

  Output on qemu 3.0.0 (Linux user-mode emulation):
  =========================================================
  fpcr = 0x07000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
  fpcr = 0x00000000.
  x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023.
  =========================================================

  Notice that after setting FPCR to zero, `r` is not equal to `q`.

  Also notice that, using another proprietary operating system, the same
  issue arises between a real board and QEMU. This might be an issue in
  emulation of the AArch64 instruction "fdiv".

  Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1
  sample1.c

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1793119/+subscriptions

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-12-12  9:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <153726785322.19300.9182114718255539260.malonedeb@wampee.canonical.com>
2018-10-10 14:23 ` [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero Emilio G. Cota
2018-10-10 14:45 ` Koutheir Attouchi
2018-12-12  9:17 ` Thomas Huth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.