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 now that someone has reported the 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
write_lp() and read_lp() can rearrange some things.

In any case, both of the above work fine on an x86_64 machine. I've
attached the lp/mps files.

edge_disjoint_spanning_trees.lp
Description: Text document

edge_disjoint_spanning_trees.mps
Description: Text document