Re: isnanf cleanup

[Jeff Johnston <jjohnstn at redhat dot com>]

----- Original Message -----
From: "Ken Werner" <ken@linux.vnet.ibm.com>
To: newlib@sourceware.org, "Jeff Johnston" <jjohnstn@redhat.com>, "Howland Craig D (Craig)" <howland@lgsinnovations.com>
Sent: Thursday, July 9, 2009 10:10:11 AM GMT -05:00 US/Canada Eastern
Subject: Re: isnanf cleanup

On Wednesday 08 July 2009 02:44:08 pm Ken Werner wrote:
> On Wednesday 08 July 2009 01:44:32 pm Ken Werner wrote:
> > On Tuesday 07 July 2009 05:46:34 pm Jeff Johnston wrote:
> > > Ken Werner wrote:
> > > > On Friday 03 July 2009 07:19:59 pm Jeff Johnston wrote:
> > > >> Hi Craig,
> > > >>
> > > >> Sorry for the delay.
> > > >>
> > > >> Patch has a problem.  It will break spu math library.  The spu will
> > > >> define isnan and isinf to not support float values which will
> > > >> override the definitions in math.h.  Don't know why SPU has those
> > > >> macros in machine/ieeefp.h but they should be rewritten to match the
> > > >> ones in math.h or removed entirely.
> > > >>
> > > >> -- Jeff J.
> > > >
> > > > Hi,
> > > > Why does this patch break the SPU math library?
> > > > The reason that the isinf and isnan macros are overwritten by the
> > > > machine/ieeefp.h is that these are evaluated at compile time and thus
> > > > faster than the math.h variant which calls fpclassify. They could be
> > > > rewritten to use fpclassify instead of __isinfd/__isnand but we don't
> > > > have an optimized __fpclassifyd routine like our vectorized isnan
> > > > code.
> > > >
> > > > -ken
> > >
> > > This breaks the SPU math library because the override macros only work
> > > for double arguments.
> > > They return 0 if the value is a float.  Craig's patch has changed the
> > > float math routines to use isnan/isinf
> > > instead of __isnanf/__isinff which is fine if one uses the macro in
> > > math.h, but in SPU's case they will never properly detect a float nan
> > > or float infinity.
> > >
> > > -- Jeff J.
> >
> > Jeff,
> > As far as I understand, the following happens when the patch is applied:
> > The machine/ieeefp.h header defines the isinf, isnan, __ieeefp_isnanf and
> > __ieeefp_isinff macros. The isinf and isnan macros expand to zero if the
> > value is a float. Otherwise they expand to __isinfd(__x) and
> > __isnand(__x)) (the prototypes are in math.h). The machine header is
> > included by the ieeefp.h which (unfortunately) undefines isnan and isinf
> > and contains prototypes for the legacy functions isnan, isinf, isnanf and
> > isinff. If the user includes math.h the isinf/isnan macros are used from
> > machine/ieeefp.h. The only concern I have is that as soon as a user
> > includes ieeefp.h, the legacy isnan/isinf functions will be used, and
> > they do not return zero in case of single precision. But this hasn't
> > changed with Craigs patch.
> >
> > -ken
>
> Oh,
> We might not have talked about the same thing here. In case you wonder why
> isnan and isinf return zero for single precision. This is intended on the
> SPU because of the many differences between strict IEEE behavior and the
> hardware behavior.
> -ken

Just to clarify: The SPU single-precision floating point format is not 
compliant to the IEEE format. There is no NAN and INF. Therefore the isnan and 
isinf macros/functions return zero for floats. I apologize for any 
misunderstandings I might have caused.

-ken

Ok, then there is nothing wrong with Craig's patch then.  I have checked it in.
Thanks for clarifying this.

-- Jeff J.