[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: lo_ieee_init: unrecognized floating point format! on ARM platform(re
RE: lo_ieee_init: unrecognized floating point format! on ARM platform(revisited)
Sat, 3 Feb 2007 22:55:23 +0000
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
> ---------- 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
> 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
> | > | 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:
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
cc: me if you have further questions.
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.
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform(revisited),