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

[Wookey]

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:

> ---------- Forwarded message ----------
> From: "John W. Eaton" <address@hidden>
> Date: Fri, 2 Feb 2007 13:52:27 -0500
> To: Simon Pickering <address@hidden>
> Subject: RE: lo_ieee_init: unrecognized floating point format! on ARM
>       platform(revisited)
> Cc: address@hidden
> 
> On  2-Feb-2007, Simon Pickering wrote:
> 
> | > | So xmax and xmin differ.
> | > | 
> | > | I have a couple of questions:
> | > | 
> | > | Why is this endianness check carried out at run-time rather than at 
> | > | compile time (in configure for example, as R does)?
> | > 
> | > Because a configure-time check will fail when cross compiling.

Full marks for thinking about cross-compiling - far too many bits of
software don't. 

> | > | 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?

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.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/                 play: http://wookware.org/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.