Alternatively 'uint64_t helper_todouble(uint32_t)' could be implemented via
include/fpu/softfloat.h:float64 float32_to_float64(float32, float_status
*status);
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad
Attaching the patch and sending for review as:
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06562.html
** Patch added: "patch to fix denormals"
https://bugs.launchpad.net/qemu/+bug/1821444/+attachment/5248915/+files/0001-powerpc-fix-denorm-float-double-conversion.patch
--
You
A bit more investigation:
It looks like the bug happens in float->double conversion direction.
$ cat a.c
#include
#include
int main() {
volatile uint32_t i = 1;
volatile float f;
volatile double d;
*(volatile uint32_t*)&f = i;
d = f;
printf("d = %#llx (expect 0x36a
Shorter example without relying on printf() implementation. Looks like
uint32_t<->float<->double transitions are enough.
$ cat a.c
#include
#include
int main() {
volatile uint32_t i = 1;
volatile float f;
volatile double d;
*(volatile uint32_t*)&f = i;
d = f; f = d; // doubl
My native system is x86_64-pc-linux-gnu with a few binfmt_misc handlers wired.
Checking other targets I have locally I get the following:
affected targets:
- powerpc
- powerpc64
- powerpc64le
unaffected targets:
- arm
- arm64
- hppa
- sparc
probably unaffected:
- alpha (maybe it's ok as alpha is n