From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtLmR-0007le-DQ for qemu-devel@nongnu.org; Wed, 18 Dec 2013 13:23:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtLmI-0002aQ-VN for qemu-devel@nongnu.org; Wed, 18 Dec 2013 13:23:35 -0500 Message-ID: <52B1E814.3060102@gmail.com> Date: Wed, 18 Dec 2013 12:23:16 -0600 From: Tom Musta MIME-Version: 1.0 References: <1386789398-5239-1-git-send-email-tommusta@gmail.com> <1386789398-5239-12-git-send-email-tommusta@gmail.com> <52A8CD67.8060804@gmail.com> <52B1DC18.4080106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [V2 PATCH 11/18] softfloat: Fix float64_to_uint32 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "qemu-ppc@nongnu.org" , QEMU Developers On 12/18/2013 12:03 PM, Peter Maydell wrote: > On 18 December 2013 17:32, Tom Musta 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.