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月14日周二 上午7:24写道：
>
> 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

With this patch to llvm-toolchain-9, this problem has been gone.
we don't need to rebuild rust for this librsvg.

-- 
YunQiang Su
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mips-force-nomadd4.diff
Type: application/octet-stream
Size: 4360 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20200714/5569a5c3/attachment.obj>