Numerical issues on ARM64/RISC-V

[Michael Orlitzky]

We have a graph test in SageMath whose underlying implementation uses
GLPK to solve a MIP. But I now have a RISC-V machine, and the test is
hanging. I also notice that someone has reported the same problem on an
ARM machine.

These "failures" depend on both the compiler and optimization level
used to build GLPK. For me, right now, GCC works only at -O0 and -O1,
while clang does not work at all.

When it works:

  $ glpsol --lp edge_disjoint_spanning_trees.lp
  ...
  GLPK Simplex Optimizer 5.0
  1864 rows, 1310 columns, 10110 non-zeros
      0: obj =  -0.000000000e+00 inf =   5.626e+02 (302)
    430: obj =  -0.000000000e+00 inf =   6.402e-14 (0) 3
  OPTIMAL LP SOLUTION FOUND
  Integer optimization begins...
  Long-step dual simplex will be used
  +   430: mip =     not found yet <=              +inf        (1; 0)
  +   763: mip =     not found yet <=   0.000000000e+00        (39; 0)
  +  1015: mip =     not found yet <=   0.000000000e+00        (89; 2)
  +  1563: mip =     not found yet <=   0.000000000e+00        (158;10)
  +  2126: mip =     not found yet <=   0.000000000e+00        (224;27)
  +  2725: >>>>>   0.000000000e+00 <=   0.000000000e+00   0.0% (322;39)
  +  2725: mip =   0.000000000e+00 <=     tree is empty   0.0% (0; 717)
  INTEGER OPTIMAL SOLUTION FOUND
  Time used:   25.0 secs
  Memory used: 3.6 Mb (3823072 bytes)


And when it fails:

  $ glpsol --mps edge_disjoint_spanning_trees.mps
  ...
  GLPK Simplex Optimizer 5.0
  1864 rows, 1310 columns, 10110 non-zeros
      0: obj =   0.000000000e+00 inf =   5.626e+02 (302)
    452: obj =   0.000000000e+00 inf =   6.244e-14 (0) 4
  OPTIMAL LP SOLUTION FOUND
  Integer optimization begins...
  Long-step dual simplex will be used
  +   452: mip =     not found yet >=              -inf       (1; 0)
  +  1015: mip =     not found yet >=   0.000000000e+00       (42; 0)
  +  1438: mip =     not found yet >=   0.000000000e+00       (107;33)
  +  2017: mip =     not found yet >=   0.000000000e+00       (149;119)

  (this goes on forever)


(Everything that I've trimmed with "..." is the same.) Both of these
files were saved from the same LP, but apparently, a round trip through
glp_write_lp() and glp_read_lp() can rearrange some things.

In any case, both of the above work fine on an x86_64 machine.

I tried to send this message once before with the lp/mps files
attached, and the ML ate them. I'm happy to provide them by some other
means.