Re: [Qemu-ppc] [Qemu-devel] [V2 PATCH 11/18] softfloat: Fix float64_to_uint32

[Peter Maydell]

On 18 December 2013 17:32, Tom Musta <address@hidden> wrote:
> On 12/17/2013 11:45 AM, Peter Maydell wrote:
>> I'm partway through fixing this bug in an implementation of
>> float*_to_uint16 which the ARM AArch64 needs. I think the
>> cleanest approach to this looks like this:
>>
>> uint32 float64_to_uint32( float64 a STATUS_PARAM )
>> {
>>     int64_t v;
>>     uint32 res;
>>     int old_exc_flags = get_float_exception_flags(status);
>>
>>     v = float64_to_uint64(a STATUS_VAR);
>>     if (v > 0xffffffff) {
>>         res = 0xffffffff;
>>     } else {
>>         return v;
>>     }
>>     set_float_exception_flags(old_exc_flags);
>>     float_raise(float_flag_invalid STATUS_VAR);
>>     return res;
>> }
>>
>> thanks
>> -- PMM
>>
>
> This seems to assume that the only case where flags could be set in
> float64_to_uint32 is the case where a large result is returned. Is
> this really the case?

No, all it's assuming is that if we have the out-of-range
case then the only flag that should be set is Invalid.
In the "result is correct" case we return v and don't
modify the flags from what float64_to_uint64() has set.

Do you think there are flags that should be allowed
to be set by the conversion operation even if it is signaling
Invalid because of out of range input? IEEE754-2008 section 7.1
says "An invocation of [any operation except directly modifying
the flags] might raise at most two status flags, overflow
with inexact or underflow with inexact". That is, any operation
might (1) raise no flags (2) raise just one flag (3) raise
Overflow+Inexact (4) raise Underflow+Inexact.
[QEMU/softfloat don't suport alternate exception handling
so we can ignore the standard's verbiage about that.]

There is also the softfloat-specific float_flag_input_denormal,
but I think that is also fine because it will only be set by the
operation if we're squashing input denormals to zero, in
which case the float-to-int conversion must always successfully
return zero (because we squashed the input to plus or minus
zero).

This is a bit complicated though, so maybe I missed a case?

thanks
-- PMM