On 12/18/2013 12:03 PM, Peter Maydell wrote: > On 18 December 2013 17:32, Tom Musta <tommu...@gmail.com> wrote: >> On 12/17/2013 11:45 AM, Peter Maydell wrote: >> >> 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 >
I'm sorry Peter ... I misread your patch. I see what you are doing now. I'll use your pattern, retest and resubmit.
