RE: lo_ieee_init: unrecognized floating point format! on ARM platform

[John W. Eaton]

On 23-Sep-2005, Simon Pickering wrote:

| I suppose I should be able to compare my output to the test cases in
| mach-info.cc, though I'll have to do some more reading to work out how to
| convert the normal numbers returned by d1mach into the tuples in the
| INIT_FLT_PAR structures.

You can do it by storing the double values in the d field of

  union equiv
  {
    double d;
    int i[2];
  };

and looking at the elements of the i field.

| I note that even if it's nothing to do with --float-store there are other
| issues to do with double rounding, etc. which may still have an effect - so
| I'll have to have a look at how machar works and see if I can work out where
| things are going wrong.

OK.

Can you try a different gcc version for this file?

| One last question - flt_fmt_cray is assumed without performing any tests,
| from the CRAY #define; this leads me (slightly OT) to ask why it can't be
| tested for (I should probably look in the mailing list archive for this
| though),

I don't think you would find anything about it.  This hack was done
for an incomplete port to a Cray SV-1 that I was working on.  I don't
remember all the details, but I think one problem was that sizeof
(int) == sizeof (double).  Maybe machar was failing to do the right
thing too.  I can't remember.  It doesn't really matter though, as
Octave will likely not work well on that system anyway.  I don't see
this as a big problem though, since there are not so many of them
around.

|  and more importantly to ask just how much of the code is in fact
| dependent on the flt_fmt type? My reason for asking this, is that even with
| the warning, the test calculations I've performed using the Zaurus appear to
| produce the correct answers; what kind of calculation would I need to
| perform to see a problem in the results?

It matters for deciding what to do for load/save in binary formats, at
least when you are swapping byte order, fread/fwrite, etc.

If you aren't concerned that your compiler might be miscompiling
machar, then just hack the flt_fmt code to force the format to be ieee
big endian and cross your fingers.  :-)

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------