I don't think it is worth the effort.  Cross-compiling is used when we have a hard time (as with Windows) getting the necessary toolchain and libraries in place.

For a MIPs processor it should be easy enough to have a Linux distribution and do a native build in which case the configure script will work correctly.

I took the easy path and added a default value of 'no' (don't use MIPS definition of NaN) for cross-compiling to the AC_RUN_IFELSE macro.  See http://hg.savannah.gnu.org/hgweb/octave/rev/8e549734531e.

I pushed a change to the stable branch that isn't perfect (http://hg.savannah.gnu.org/hgweb/octave/rev/e9b7ac7031fb), but does allow NA to work by default on MIPS architectures.

Ideally, the configure test OCTAVE_MIPS_NAN would check the actual value of the high word in an IEEE quiet NaN and see whether it is the non-standard value.  Right now, it just assumes that if your target is MIPS then you are using the non-standard option.  This is the default, but someone might build with the '-mnan=2008' option at some point.

The issue of binary compatibility of files saved with NA values could be addressed by changing the __lo_ieee_replace_old_NA() function in liboctave/utils/lo-ieee.cc.  Right now that function is called when loading double values from a binary file and updates any old values of NA to the new value of NA.  It could be extended to also search for any MIPS NA value and replace with the architecture-specific value of NA.

These are definitely edge cases, and I don't use MIPS so I don't have an incentive to work on this.  As a workaround, you could save data using Octave's -text format along with the '-z' flag to compress the resulting file.

Hmm, it could get to be time consuming to support ARM if there are a lot of instances where this is going to diverge from all the other processor architectures.

What happens if you undo my patch, add '-mnan=2008' to your CXXFLAGS, CFLAGS, and FFLAGS variables, and re-compile Octave from scratch?  Do operations with NA work correctly?  Does 'make check' pass?

comment #13:

> It seems that re-defining Octave NA to be a quiet signaling NaN on MIPS architectures will resolve this issue.  To be absolutely certain, could you use this custom-built version of Octave and try running the BIST tests for the level-set package and see if they pass?

I did the required test. I compiled Octave on a mips64el system with your LO_IEEE_NA_HW patch and used that version to run the 18 BISTs in function so_step_armijo of the level-set package, all of which passed.

The last test seems to have worked which means this might be a way forward.  According to your post, you tried for verification

y = x / NA
+verbatim+

I actually wanted to verify

+verbatim+
y = x / 4

Does that also result in isna (y) being true?

And if it does, can you use this custom version of Octave to run the BIST tests in the level-set package and see if they pass now?

The specific value of NA was chosen to be exactly the same as the corresponding value in R so that saving and loading data in binary format would preserve the value when transferring data between Octave and R.  I had initially hoped we would maybe modify functions in Octave to actually respect NA values when appropriate, but that hasn't ever happened since NA was added to Octave nearly 20 years ago.  Maybe it would make more sense to just deprecate and drop NA from Octave?

Can you try this?

format native-bit
x = NA
x / 4

Also, one thing I notice is that the silent signaling bit for NaN in IEEE is turned on in Octave according to the IEEE 2008 format.  However, as I noted in comment #6 and is shown in your comment #7, MIPS systems seem to use a value of '0' to indicate quiet signaling by default.

Trying to reverse that convention would require using the '-mnan=2008' option not just for Octave, but for all the libraries it links to.  That sounds hard.

Instead, you might try re-defining the high word of Octave NA so that the quiet signaling bit is '0' to match MIPS.  As another test, I would ask you to try changing liboctave/util/lo-ieee.h.

diff -r e4c152e827aa liboctave/util/lo-ieee.h
--- a/liboctave/util/lo-ieee.h        Thu Jan 07 18:34:18 2021 +0100
+++ b/liboctave/util/lo-ieee.h        Fri Jan 08 14:09:31 2021 -0800
@@ -69,7 +69,7 @@ typedef union

 #define LO_IEEE_NA_HW_OLD 0x7ff00000
 #define LO_IEEE_NA_LW_OLD 1954
-#define LO_IEEE_NA_HW 0x7FF840F4
+#define LO_IEEE_NA_HW 0x7FF040F4
 #define LO_IEEE_NA_LW 0x40000000
 #define LO_IEEE_NA_FLOAT   0x7FC207A2

Apply the patch with 'patch -p1 < mypatch' and then re-compile.

Try

format native-bit
x = NA
y = x / 4
isna (y)

I suspect there isn't going to be a good solution.

See the file liboctave/utils/lo-ieee.h.

Octave defines an NA value to be composed of two 32-bit values.

#define LO_IEEE_NA_HW 0x7FF840F4
#define LO_IEEE_NA_LW 0x40000000

The routine that decides whether something is NA versus NaN is

int
__lo_ieee_is_NA (double x)
{
  lo_ieee_double t;
  t.value = x;
  return (__lo_ieee_isnan (x) && t.word[lo_ieee_hw] == LO_IEEE_NA_HW
          && t.word[lo_ieee_lw] == LO_IEEE_NA_LW) ? 1 : 0;
}

The IEEE standard defines NaN as having the sign bit cleared, maximum possible exponent, and a mantissa which is non-zero.  Thus, the high word begins with 0x7FF.  Most mathematical libraries detect NaN and then don't further process the number.  So when you operate on an NA value in an IEEE-compliant library the value just passes through.  However, this is implementation dependent.  My guess is that the ARM software library, or hardware implementation, detects that the value is a NaN and then substitutes a constant NaN value such as 0x7FF80000.  This value is also NaN according to IEEE standards, but it is no longer an Octave NA because the values have changed.  If you can compile with a debugger you could check whether this is correct.

There may be special switches you can throw during compilation to determine how IEEE operations are implemented (such as not using 80bit precision, etc.).  Maybe there is something that might be useful for MIPS?  In gcc, for example, I see '-mhard-float' to require use of HW math co-processor and '-msoft-float' to use software libraries for floating point.

This option also looks promising

-mnan=2008
       -mnan=legacy
           These options control the encoding of the special not-a-number (NaN) IEEE 754 floating-point
           data.

           The -mnan=legacy option selects the legacy encoding.  In this case quiet NaNs (qNaNs) are
           denoted by the first bit of their trailing significand field being 0, whereas signaling NaNs
           (sNaNs) are denoted by the first bit of their trailing significand field being 1.

           The -mnan=2008 option selects the IEEE 754-2008 encoding.  In this case qNaNs are denoted by
           the first bit of their trailing significand field being 1, whereas sNaNs are denoted by the
           first bit of their trailing significand field being 0.

If you can verify with a debugger first I think that would be the best first step.

Okay, at least defining an NA value is possible.

Next step is to isolate the problem and see which mathematical operations preserve NA and which convert it to NaN.  Just guessing right now, it is more likely that a hardware accelerated multiplication/division is going to change things.

Tests:

x = NA;
x + 1
x - 1
x * 1
x / 1

Very strange.

On the mips64el system, is every NA translated to NaN?  For example, does this print NA and 1?

x = NA
isna (x)

What happens when you try to perform the logical operation ~x?

y = ~x

I get an error message on Linux.

Octave is producing different results for arithmetic operations involving NA in different architectures of Debian GNU/Linux.  On a amd64 system, I get:

$ echo "NA / 1" | octave-cli
ans = NA

while on a mips64el system, I get:

$ echo "NA / 1" | octave-cli
ans = NaN

This is preventing a BIST in the level-set package to succeed on a mips64el system.

Does anyone know the cause for this disparity?