On 2020-05-06 11:19, Simon McVittie wrote: > Control: forwarded -1 https://gitlab.gnome.org/GNOME/librsvg/-/issues/580 > Control: found -1 2.48.2-1 > > On Wed, 06 May 2020 at 08:54:04 +0100, Simon McVittie wrote: > > > failures: > > > > > > ---- transform::tests::parses_transform_list stdout ---- > > > thread 'transform::tests::parses_transform_list' panicked at 'assertion > > > failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))', > > > rsvg_internals/src/transform.rs:398:9 > > > > > > ---- transform::tests::parses_valid_transform stdout ---- > > > thread 'transform::tests::parses_valid_transform' panicked at 'assertion > > > failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))', > > > rsvg_internals/src/transform.rs:398:9 > > > > > > > > > failures: > > > transform::tests::parses_transform_list > > > transform::tests::parses_valid_transform > > > > > > test result: FAILED. 172 passed; 2 failed; 0 ignored; 0 measured; 0 > > > filtered out > > This seems to be either intermittent or machine-dependent: when retried > on a different machine, the tests often pass. > > 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. I guess that explain the difference. I am going to blacklist librsvg from the Loongson 3A based buildds so that it doesn't happen again. That's not ideal but it's the best we can do with the currently available hardware. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net