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

[John W. Eaton]

On  2-Feb-2007, Simon Pickering wrote:

|  
| > | The values returned by Octave (either using format bit, or the patched 
| > | version of machar) on the Nokia 770 are as follows:
| > | 
| > | eps      2.2204460492503131e-16          0   3CB00000
| > | epsneg   1.1102230246251565e-16          0   3CA00000
| > | xmin    4.9406564584124654e-324          1          0
| > | xmax                        inf          0   7FF00000
| > | 
| > | 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.
| 
| Yes, fair enough, and I suppose the check is only run once at start-up so it
| doesn't add much overhead.
| 
| > | 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?

jwe