Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed:
t1.y0.approx_eq(t2.y0, (epsilon, 1))
Control: severity -1 wishlist
Control: tags -1 + confirmed wontfix
Control: notforwarded -1
On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote:
> On 2020-05-06 11:19, Simon McVittie wrote:
> > There seems to be a strong correlation where this test passes on a Rhino
> > Labs UTM8 but fails on a Loongson 3A. Are there known issues with
> > Loongson 3A hardware, or is there different FPU behaviour, or something?
>
> Thanks for the analysis. Yep the Loongson 3A is known for having an FPU
> bug that could explain that behaviour. Basically it treats the madd,
> msub, nmadd and nmsub instructions as fused while they should not.
It seems strange to me that a release architecture is using
known-to-be-faulty hardware for buildds. Is there any possibility of
replacing those machines, or taking them out of the buildd rotation
entirely?
In particular, we treated this as a RC bug, and prioritized reporting
it upstream; but we should not be wasting upstreams' time with issues
that are a result of faulty hardware. I don't think we can expect every
package maintainer, or every upstream maintainer, to know that Debian's
mips*el buildds have this bug and that failing build-time tests that
touch floating-point are likely to be not a real bug in the software.
At the same time, I don't want to disable build-time tests or ignore
their results, because for most architectures they are the only evidence
we have that a package works at all.
> I am going to blacklist librsvg from the Loongson 3A based buildds so
> that it doesn't happen again.
Thanks. I'll add a check to d/rules to make the build fail sooner if a
Loongson-3A CPU is detected (when not building with nocheck), to make
sure this blacklisting mechanism doesn't regress.
smcv
