Andrew Troschinetz wrote: > On Jul 15, 2009, at 3:44 AM, Andrew Haley wrote: > >> On 07/14/2009 10:44 PM, Andrew Troschinetz wrote: >>> But for floating point types doesn't this signature run the risk of the >>> compiler putting a byteswapped floating point value into an FPU >>> register, thus causing the data to be modified? >> >> Why would it? Perhaps you're concerned that loading into a FPU >> register would convert a signaling NaN into a quiet NaN, or >> somesuch? > > It is not an area in which I am well versed so I probably can't give you > as good an answer as others on this list, but I'll give it a go. "Why > would it?" isn't actually a valid question, you should be asking "why > does it?" because all the tests I've done show that it does. OK. I'd be very interested to know what values cause problems. > I believe the problem is that not all values of the sign, exponent, and > mantissa of a floating point number are valid under IEEE 754. There isn't really any redundancy in IEEE 754. Even when a value is NaN, the payload is supposed to be preserved through loads and stores. It is quite possible, though, that on some machines sNaNs get turned into qNaNs by the act of loading into registers. I'm interested to know if that happens, hence my question. I don't think it should happen, but I'm quite prepared to believe that sometimes it does. > When you byteswap a valid floating point value you are very likely > to get an invalid IEEE 754 floating point value, especially with > single precision types. You may well get a NaN, but a NaN is not an invalid IEEE 754 floating point value. I don't think there is any such thing. Andrew.
