This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Byteswapping floating point types
Andrew Troschinetz wrote:
> 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
The x86_64 has a very different floating-point architecture from the
x86.
> 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.
That's a mystery to me. Any attempt to load an sNaN into a floating-
point register should generate this behaviour. gcc 4.4.0 "fails" in
the same way.
> 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:
Can't he find a task more suited to his skills? Farming, perhaps.
> 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?
No.
> 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?
No. An attempt to load a signaling NaN from memory into the FPU generates
an invalid-operation exception. If that exception is masked, the FPU
returns a quiet NaN. [1]
Andrew.
[1] 8.5.1.2. INVALID ARITHMETIC OPERAND EXCEPTION (#IA), IA-32 Intel Architecture
Software Developerâs Manual, Basic Architecture, Order Number 245470, 2001.