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
