Re: [boost] [endian] Floating point reversal return by value concerns

Subject: Re: [boost] [endian] Floating point reversal return by value concerns
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-03-18 13:23:01

On Wed, Mar 18, 2015 at 1:12 PM, John Maddock <jz.maddock_at_[hidden]> wrote:
>
>
> On 18/03/2015 11:36, Beman Dawes wrote:
>>
>> On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green <cliffg_at_[hidden]>
>> wrote:
>>>
>>> ..., I do have concern about one aspect of the new functionality (or
>>> maybe I didn't read deep enough in the docs) - floating point endian
>>> reversal functions which return by value.
>>>
>>> Unless something has significantly changed in the last few years,
>>> swapping
>>> and returning floating point values is likely to silently change bits for
>>> certain bit patterns / values. In particular, returning by value will
>>> normalize some values (I assume as part of loading or accessing the value
>>> into floating point CPU registers). There may be other floating point
>>> characteristics that silently change the bits dealing with NaN and
>>> infinity
>>> values (but I'm far from an expert on floating point computations).
>>
>> Could you please provide code for one or more return-by-value test
>> cases that fail because the value gets normalized?
>>
>> I'm really hesitant to change anything without having test cases to
>> work with. That would also help with documenting the specifics of the
>> problem.
>
>
> I don't think this should *ever* happen - well with one possible exception -
> on Intel x87 hardware an 80-bit register value may get rounded to a 64-bit
> value at unpredictable times (ie only when it's written to memory).  I can't
> see that would be an issue here since Beman is already doing bit-fiddling on
> the value, it must by it's very nature be in memory and not a register.  I
> don't remember the specifics but return by value may actually be a
> return-by-register for some ABI's....

>ah wait.... Beman are you returning by
> value a non-native representation?

Yes.

>  If so I imagine that may be an issue as
> the value gets moved to and from a register: some bit values are not
> permitted I believe - it's anybodies guess what the hardware would do to
> those?

Ouch!

>   You could actually test all possible bit-patterns in a float and
> see if this is a real issue?

That's doable. I'll give it a try.

--Beman