Re: NA and NaN representation on mips64el
Rafael Laboissière <rafael@debian.org> 于2025年5月13日周二 00:30写道：
>
> Dear mips porters,
>
> I need some advice on an FTBFS problem with package octave mapping on the
> mips64el architecture. Here is the log for the failed build:
>
> https://buildd.debian.org/status/fetch.php?pkg=octave-mapping&arch=mips64el&ver=1.4.3-1&stamp=1746884958&raw=0
>
> It also FTBFS on riscv64, for the same reason: the unit tests for
> degrees2dm and degrees2dms fail with this error:
>
Seems strange...
> ***** assert (degrees2dm (NA), [NA NA]) !!!!! test failed ASSERT errors for: assert (degrees2dm (NA), [NA,NA])
>
> Location | Observed | Expected | Reason
> (1) NaN NA 'NA' mismatch
> (2) NaN NA 'NA' mismatch
>
> It seems to be a problem related to how floating point NA and NaN are
> represented.
>
> Strangely, I cannot reproduce this problem. I built the package manually
> on a mips64el porterbox using schroot and everything worked fine.
>
I see. The problem is that the machine (mipsel-osuosl-03.debian.org)
is Loongson 3A4000.
The problem is that MIPS swap the encodings of sNaN and qNaN since MIPSr5.
I guess that octave uses sNaN as NA?
We have no good solution for it. We have meet some other packages
with this case.
Let's just ask the help from DSA to pin this package on non-3A4000 machines.
> We discussed a similar issue on the upstream bug tracking system for
> Octave back in 2021: https://savannah.gnu.org/bugs/?59830
>
> One of the upstream authors seems to suggest that this problem is related
> to cross-compiling.
>
> Do you know if there is a way to work around this?
>
> Best,
>
> Rafael Laboissière
>
--
YunQiang Su
Reply to: