YunQiang Su <wzss...@gmail.com> 于2020年7月14日周二 上午7:24写道： > > Yunqiang Su <wzss...@gmail.com> 于2020年7月10日周五 上午8:14写道： > > > > On Mon, 11 May 2020 13:15:23 +0100 Simon McVittie <s...@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
mips-force-nomadd4.diff
Description: Binary data
