Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))

[Yunqiang Su]

On Mon, 11 May 2020 13:15:23 +0100 Simon McVittie <smcv at debian.org> wrote:
> 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.

For gcc, we patched it to not use madd.fmt. We should so the same thing to llvm.
Let’s do it.

> 
>     smcv
> 
>