This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]