Richard Henderson <richard.hender...@linaro.org> writes: > On 04/17/2018 01:08 PM, Peter Maydell wrote: >> On 18 April 2018 at 00:01, Peter Maydell <peter.mayd...@linaro.org> 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.
It does seem to be floating point is a rabbit hole that everyone gets something wrong if you look too closely! -- Alex Bennée
