Add linux arm build to CI

[olemke]

[olemke]

@riclarsson conda-forge doesn't have packages for Windows ARM yet, so no build for that for now.

[riclarsson]

@olemke Excellent! It builds quite fast. I guess few people are using these cores :)

The std::abs thing... what actually happens? is this related to arm or a separate bug?

[olemke]

@riclarsson The abs thing is an arm thing. Without std::, the compiler uses the int instead of float version of abs. Which surprised me since we're using the same GCC compiler version on x86 and don't get this issue:

/home/runner/work/arts/arts/src/core/scattering/phase_matrix.h:96:13: error: no matching function for call to 'equal(int, double)'
   96 |       (equal(abs(aa_scat - aa_inc), 2.0 * pi_v<Scalar>))) {
      |       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

https://github.com/olemke/arts/actions/runs/19571385116/job/56045515247#step:7:457 (not sure if github let's you view this) Similar here: https://github.com/atmtools/arts/actions/runs/19664055131/job/56316610489#step:7:70

There is another bunch of warnings, would be interesting to hear your opinion on what we should do about those:

/home/runner/work/arts/arts/src/core/lbl/lbl_data.h:229:69: warning: the result of the conversion is unspecified because '-1' is outside the range of type 'LineShapeModelVariable' [-Wconversion]
  |   LineShapeModelVariable ls_var{static_cast<LineShapeModelVariable>(-1)};
  |                                                                     ^~

https://github.com/atmtools/arts/actions/runs/19694341913/job/56416288579#step:8:313

And also for this one, why doesn't GCC show the same warning on x86? 🤷‍♂️

[riclarsson]

The compiler is correct, -1 is not a valid enum value. I use it because it is invalid (so that the result is invalid.

There are options if you want to have a fix:

1. Make each type that can have an invalid state also have an invalid value.
2. Make each of these a std::optional.

Edit: I'll implement the first one.

[olemke]

Exactly, it's a pretty clear case, why it's even more surprising that the warning is not thrown for x86. I would expect GCC to behave the same independent of architecture here.