Byteswapping floating point types

[Andrew Troschinetz]

On Jul 14, 2009, at 4:44 PM, Andrew Troschinetz wrote:

> Testing with GCC 3.5.x to GCC 4.x has shown that this issue doesn't  
> surface unless you attempt some mathematical operation on the float  
> containing a byteswaped value. In other words:

That was me talking about results on my x86_64 machine, I went to my  
i686 machine instead of my x86_64 machine and tried this code: http://codepad.org/OZhEz0az

If I use GCC 2.95, or GCC 3.4.6 to compile the code and run it, the  
problem presents itself. But if I use GCC 4.1.2 the code compiles and  
runs just fine.

Unfortunately we're in a position where we need to support at least  
GCC 3.4.6 on i686 hardware, so this problem affects us. My co-worker  
has, predictably, expressed dismay that returning a float as a byte- 
sequence, accommodating unsigned int type, or a user defined swapped  
type is unnecessarily complicated. And that if the test fails it is  
because of some kind of misconfiguration or compiler bug. He actually  
suggested a comment in the header file that says "this may not work on  
floating point types" as a good resolution to this issue. D:

On Jul 15, 2009, at 12:20 PM, Andrew Haley wrote:

> Well, it looks like our lovely (?) hardware is indeed silently  
> converting a signaling NaN to a quiet NaN, as I guessed.  Thanks for  
> the test case; it's always nice to know the real reason for things.

Doesn't this new information suggest that the problem is in the  
compiler, and not the hardware? And might there a way perhaps to force  
GCC to generate code that will not cause this problem to arise? Maybe  
something like --no-nan-quietification?

I tried -fsignaling-nans but that didn't do the trick.

--
Andrew Troschinetz
Applied Research Laboratories