Dave ran the above testcase on:
> processor : 0
> cpu : POWER8E (raw), altivec supported
> clock : 3325.00MHz
> revision : 2.1 (pvr 004b 0201)
And there are no diffs with what you currently get from master. So I
think the invalid flag fault is fixed by a previous
It looks like the test case isn't properly exercising the code that is
likely to be wrong. It sounds like we need a proper comprehensive
testcase for fused operations (along the line of the ARM fcvt test
case). This can probably be a multiarch testcase which we can build for
all the various
Testing on current master shows the behavior is correct. I guess rth's
patch fixed this case.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
It should be a fused multiply add; you may need to use -ffast-math or
something to get the compiler to generate the proper instruction.
However, one can see from target/ppc/translate/fp-impl.inc.c:
/* fmadd - fmadds */
GEN_FLOAT_ACB(madd, 0x1D, 1, PPC_FLOAT);
through to _GEN_FLOAT_ACB:
I'm confused by this testcase as it's not a fused multiply-add but as
you say two combined operations.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841592
Title:
ppc: softfloat float
** Tags added: ppc64 testcase
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841592
Title:
ppc: softfloat float implementation issues
Status in QEMU:
New
Bug description:
Per bug #1841491,
-- ppc64le native:
$ gcc -c -O2 ffma.c
$ gcc -O2 test-ffma.c ffma.o -lm -o test-ffma
$ ./test-ffma $(./test-ffma)
ffma(0x1p-149, 0x1p-149, 0x1p-149)
0x0
0xa00
FE_INEXACT FE_UNDERFLOW
0x1p-149
-- qemu-system-ppc64:
$ ./test-ffma $(./test-ffma)
ffma(0x1p-149, 0x1p-149, 0x1p-149)
0x0
