Re: [Qemu-devel] [PATCH] fpu/softfloat: check for Inf / x or 0 / x before /0

[Richard Henderson]

On 04/17/2018 01:08 PM, Peter Maydell wrote:
> On 18 April 2018 at 00:01, Peter Maydell <address@hidden> wrote:
>> I don't have the original IEEE754 spec to hand though;
>> that may have left this unspecified.
> 
> Having located a copy of 754-1985 I think that also is
> clear enough that float-float conversion is an operation
> that must quieten SNaN and raise Invalid.

That does seem to match actual processor behaviour.
The attached test case produces

7fa00000
7ffc000000000000 - 1
7ff4000000000000
7fe00000 - 1

on both x86_64 and aarch64.

For ppc64, I believe there's a compiler bug:

7fa00000
7ff4000000000000 - 0
7ff4000000000000
7fe00000 - 536870912

convert float to double:
    1000074c:   60 00 01 c0     lfs     f0,96(r1)
    10000750:   68 00 01 d8     stfd    f0,104(r1)

convert double to float:
    100007a8:   68 00 01 c8     lfd     f0,104(r1)
    100007ac:   18 00 00 fc     frsp    f0,f0
    100007b0:   60 00 01 d0     stfs    f0,96(r1)

Floating point numbers are held in a "register" format that largely corresponds
to double-precision.  Thus the compiler believes that loading a
single-precision value and then storing it out again as a double is sufficient.
 However, as we can see above that does not consider SNaN.

There is no ppc "convert single to double" instruction, there is only a "round
to single precision" instruction -- frsp.  However, if we assume that the
single precision number is already properly rounded, then we can add an extra
frsp and it will not normally affect the value at all; it will only change the
contents for snan.

If I manually add the frsp insn to the code generated for the test case I get

7fa00000
7ffc000000000000 - 536870912
7ff4000000000000
7fe00000 - 536870912

exactly as we expect.  I'll file a bug vs gcc.


r~

z.c
Description: Text Data