Re: PATCH RFA: Fix simulator handling of floating point absolute value

[Ian Lance Taylor <ian at airs dot com>]

Daniel Jacobowitz <drow@false.org> writes:

> On Thu, Jul 07, 2005 at 10:18:53PM -0700, Ian Lance Taylor wrote:
> > The common simulator routine sim_fpu_abs is used by MIPS, MN10300,
> > SH64, and perhaps some CGEN generated simulators (it is called by
> > cgen-accfp.c).  On most, and perhaps all, hardware, a floating point
> > absolute value instruction simply clears the sign bit.  However,
> > sim_fpu_abs does not clear the sign bit when given a NaN.  For MIPS,
> > this causes the gcc test gcc.c-torture/execute/ieee/copysign1.c to
> > fail.
> > 
> > This patch changes sim_fpu_abs to always clear the sign bit of the
> > argument.  It does not otherwise change the behaviour.  This, plus
> > another patch I am about to sign, fixes the gcc copysign1 test for
> > MIPS.
> > 
> > OK for mainline?
> 
> I have no references for this concern, but could you check that this
> change is appropriate for at least MN10300 and SH64, since they share
> ths code?

I think I'll need a little help to fully satisfy this request.  The
issue is how the fabs instruction on the MN10300 and SH handle NaNs.
This is something that can only be determined via a detailed processor
manual or by testing on real hardware.

The manual for the SH4a is, fortunately, clear: the fabs instruction
is described as "FRn & H'7FFF FFFF -> FRn."  So for the SH4a, at
least, my proposed patch is correct.

I found a processor manual for the MN10300 AM33 on the web, but all it
says about the fabs instruction is "This takes an absolute value of
the register (FSm), and stores the result in the register (FSn)."

A hardware designer implementing the floating point absolute
instruction has a choice.  He or she can implement a simple
instruction which clears the sign bit.  Or he or she can implement an
instruction which checks for NaN input, and, in that case, does not
clear the sign bit.  Since sim-fpu.c is intended to be for generic
use, I think it is reasonable to bet on the simple implementation, and
force a simulator for a processor which takes the complex
implementation to do something different.  Especially since it is
correct for at least two out of three processors.

Ian