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