From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33859 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PcRsT-0008Nc-Gz for qemu-devel@nongnu.org; Mon, 10 Jan 2011 19:14:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PcRsS-0000Zz-2Z for qemu-devel@nongnu.org; Mon, 10 Jan 2011 19:14:21 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:54166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PcRsR-0000Zt-S2 for qemu-devel@nongnu.org; Mon, 10 Jan 2011 19:14:20 -0500 Received: by wyg36 with SMTP id 36so21901813wyg.4 for ; Mon, 10 Jan 2011 16:14:19 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1293979183-27108-4-git-send-email-aurelien@aurel32.net> References: <1293979183-27108-1-git-send-email-aurelien@aurel32.net> <1293979183-27108-4-git-send-email-aurelien@aurel32.net> Date: Mon, 10 Jan 2011 18:14:18 -0600 Message-ID: Subject: Re: [Qemu-devel] [PATCH 3/3] target-ppc: fix sNaN propagation From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org, Alexander Graf On 2 January 2011 08:39, Aurelien Jarno wrote: > The current FPU code returns 0.0 if one of the operand is a > signaling NaN and the VXSNAN exception is disabled. > > fload_invalid_op_excp() doesn't return a qNaN in case of a VXSNAN > exception as the operand should be propagated instead of a new > qNaN to be generated. Fix that by calling fload_invalid_op_excp() > only for the exception generation (if enabled), and use the softfloat > code to correctly compute the result. > > Cc: Alexander Graf > Signed-off-by: Aurelien Jarno > @@ -1410,10 +1418,10 @@ uint64_t helper_frsp (uint64_t arg) > =C2=A0 =C2=A0 if (unlikely(float64_is_signaling_nan(farg.d))) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* sNaN square root */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0farg.ll =3D fload_invalid_op_excp(POWERPC_EXCP= _FP_VXSNAN); > - =C2=A0 =C2=A0} else { > - =C2=A0 =C2=A0 =C2=A0 f32 =3D float64_to_float32(farg.d, &env->fp_status= ); > - =C2=A0 =C2=A0 =C2=A0 farg.d =3D float32_to_float64(f32, &env->fp_status= ); > =C2=A0 =C2=A0 } > + =C2=A0 =C2=A0f32 =3D float64_to_float32(farg.d, &env->fp_status); > + =C2=A0 =C2=A0farg.d =3D float32_to_float64(f32, &env->fp_status); > + > =C2=A0 =C2=A0 return farg.ll; > =C2=A0} Most of these changes are to ignoring the result from fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN), but this one leaves it assigning a value to farg.ll -- is there any reason for that? (It looks like the assignment gets immediately overwritten by the assignment to farg.d later.) > @@ -1460,11 +1468,11 @@ uint64_t helper_fres (uint64_t arg) > =C2=A0 =C2=A0 if (unlikely(float64_is_signaling_nan(farg.d))) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* sNaN reciprocal */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 farg.ll =3D fload_invalid_op_excp(POWERPC_EXC= P_FP_VXSNAN); > - =C2=A0 =C2=A0} else { > - =C2=A0 =C2=A0 =C2=A0 =C2=A0farg.d =3D float64_div(float64_one, farg.d, = &env->fp_status); > - =C2=A0 =C2=A0 =C2=A0 =C2=A0f32 =3D float64_to_float32(farg.d, &env->fp_= status); > - =C2=A0 =C2=A0 =C2=A0 =C2=A0farg.d =3D float32_to_float64(f32, &env->fp_= status); > =C2=A0 =C2=A0 } > + =C2=A0 =C2=A0farg.d =3D float64_div(float64_one, farg.d, &env->fp_statu= s); > + =C2=A0 =C2=A0f32 =3D float64_to_float32(farg.d, &env->fp_status); > + =C2=A0 =C2=A0farg.d =3D float32_to_float64(f32, &env->fp_status); > + > =C2=A0 =C2=A0 return farg.ll; > =C2=A0} > Ditto for this hunk. Looks plausible to me other than that. -- PMM