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]

Yunqiang Su <wzssyqa at gmail.com> 于2020年7月10日周五 上午8:14写道：
>
> 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.

Your code about block Loongson has some problem,
The cpuinfo of my Loongson 3A 2000 machine is like:
     cpu model               : ICT Loongson-3 V0.8  FPU V0.1

3B1500, it is
     cpu model        : ICT Loongson-3 V0.7  FPU V0.1

feel free about it. I have figure out a patch to disable madd.fmt insns.
Wish it can just fix this problem.

> >
> > 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
> >
> >



-- 
YunQiang Su