On Fri, Jan 06, 2017 at 09:01:17AM +1100, David Gibson wrote: > On Thu, Jan 05, 2017 at 04:56:08PM +0530, Nikunj A Dadhania wrote: > > From: Bharata B Rao <bhar...@linux.vnet.ibm.com> > > > > Use float64 argument instead of unit64_t in helper_compute_fprf() > > This allows code in helper_compute_fprf() to be reused later to > > work with float128 argument too. > > > > Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> > > Signed-off-by: Nikunj A Dadhania <nik...@linux.vnet.ibm.com> > > Uh.. how can this possibly be correct, without updating the callers of > helper_compute_fprf()?
It works currently because uint64_t argument that is passed by the callers is interpreted as float64 arg (via farg.d). Let me see if there is a cleaner way of doing this. Casting the callers with right floatXX type seems to be the easiest way. The requirement here is to ensure that helper_compute_fprf_float16(CPUPPCState *env, float16 arg) helper_compute_fprf_float32(CPUPPCState *env, float32 arg) helper_compute_fprf_float64(CPUPPCState *env, float64 arg) helper_compute_fprf_float128(CPUPPCState *env, float128 arg) get autogenerated with right floatXX argument so that it can directly be used with required routines (like floatXX_is_any_nan etc) w/o needing the CPU_DoubleU or other intermediate forms. Regards, Bharata.
