RE: lo_ieee_init: unrecognized floating point format! on ARM platform(revisited)

[Simon Pickering]

> On 2007-02-03 04:47 +0000, P.J.G. Long wrote:
> 
> I haven't been following this thread at all, but was forwarded this
> mail:
> 

<snip>

> > | > | Is the test designed to test the endianness, or the correctness 
> > | > | of the fp implementation. I ask because I think there are simpler 
> > | > | ways to check endianness if that's all that's needed.
> > | > 
> > | > We need to know whether it is IEEE big/little endian.  If your 
> > | > system really does implement one of these, then it is surprising 
> > | > that xmax and xmin are different.  In particular, xmax looks wrong 
> > | > because it should not be Inf.  What does paranoia compute for 
> > | > these values?
> > | 
> > | The paranoia output is rather long, and I'm not sure whether the 
> > | list accepts attachments so here's a link to the output in a text file:
> > | http://people.bath.ac.uk/enpsgp/benchmarks/770-paranoia-output.txt
> > | 
> > | >From this, it would appear that the system is IEEE compliant.
> > 
> > The output from your paranoia run includes:
> > 
> >  The Underflow threshold is 2.22507385850720188e-308,  below which  
> > Overflow threshold is V  = 1.79769313486231571e+308 .
> > 
> > which appear to be the expected values for IEEE doubles. So why does 
> > machar get these wrong on your system?  It seems there is a bug in 
> > machar, or it is being miscompiled.  What happens if you turn off all 
> > optimization when compiling machar?  Does it still generate bad xmin 
> > and xmax values?
> > 
> > Maybe we should move this to the bug list?

Fine by me.

I will test this and make sure there's no optimisation switched on. The previous
run was compiled using no -O flags; can there be default optimisations that I
should also switch off with -O0 for example?

> If you are having problems with ARM Doubles the reason is 
> almost certain to be the unusual mixed-endian double format 
> used on old-ABI little-endian arm. See 'porting info' on this page:
> http://wiki.debian.org/ArmPort
> for a description if the issue and link to more detailed doc. 
> 
> This can be fixed by either getting glibc to do the double 
> reading/writing or explicitly swapping the top and bottom 
> words when reading/writing doubles.
> 
> cc: me if you have further questions.

I don't think this is the problem with the Nokia 770 and N800 as the toolchain
and platforms in question use an EABI toolchain and VFP soft-float rather than
the old FPA soft-float you mention. You can see that the byte and word order are
both little-endian from the results of the machar binary (excepting the Inf that
doesn't match).

This is, however, the problem that afflicted my initial attempts to run Octave
and caused the answers to be switched around (bigendian word order) but still
recognisable (little-endian byte order). I'm not sure that this would have any
affect on the current situation, but it would be nice to handle it too for those
who run 2.4.x (and early 2.6.x) kernels on their ARM platforms.

Regards,


Simon