fails one test on i386

[jonassmedegaard]

Testsuite fails on i386:

159s    Compiling fast-srgb8 v1.0.0 (/usr/share/cargo/registry/fast-srgb8-1.0.0)
159s      Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=fast_srgb8 CARGO_MANIFEST_DIR=/usr/share/cargo/registry/fast-srgb8-1.0.0 CARGO_PKG_AUTHORS='Thom Chiovoloni <chiovolonit@gmail.com>' CARGO_PKG_DESCRIPTION='Very fast conversions between linear float and 8-bit sRGB (with no_std support).' CARGO_PKG_HOMEPAGE='https://github.com/thomcc/fast-srgb8' CARGO_PKG_LICENSE='MIT OR Apache-2.0 OR CC0-1.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=fast-srgb8 CARGO_PKG_REPOSITORY='https://github.com/thomcc/fast-srgb8' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=1.0.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 LD_LIBRARY_PATH='/tmp/tmp.AD4YFeLxOb/target/debug/deps:/usr/lib' rustc --crate-name fast_srgb8 --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=0d6433436c5c8abd -C extra-filename=-0d6433436c5c8abd --out-dir /tmp/tmp.AD4YFeLxOb/target/i686-unknown-linux-gnu/debug/deps --target i686-unknown-linux-gnu -C incremental=/tmp/tmp.AD4YFeLxOb/target/i686-unknown-linux-gnu/debug/incremental -L dependency=/tmp/tmp.AD4YFeLxOb/target/i686-unknown-linux-gnu/debug/deps -L dependency=/tmp/tmp.AD4YFeLxOb/target/debug/deps -C debuginfo=2 --cap-lints warn -C linker=i686-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix /usr/share/cargo/registry/fast-srgb8-1.0.0=/usr/share/cargo/registry/fast-srgb8-1.0.0 --remap-path-prefix /tmp/tmp.AD4YFeLxOb/registry=/usr/share/cargo/registry`
160s     Finished test [unoptimized + debuginfo] target(s) in 1.20s
160s      Running `/tmp/tmp.AD4YFeLxOb/target/i686-unknown-linux-gnu/debug/deps/fast_srgb8-0d6433436c5c8abd`
160s 
160s running 3 tests
160s test tests::test_exhaustive_scalar ... ignored
160s test tests::test_exhaustive_simd ... ignored
160s test tests::test_from_srgb8 ... FAILED
160s 
160s failures:
160s 
160s ---- tests::test_from_srgb8 stdout ----
160s thread 'tests::test_from_srgb8' panicked at 'assertion failed: `(left == right)`
160s   left: `[0.0, 0.000303527, 0.000607054, 0.00091058103, 0.001214108, 0.001517635, 0.0018211621, 0.002124689, 0.002428216, 0.002731743, 0.00303527, 0.0033465356, 0.003676507, 0.004024717, 0.004391442, 0.0047769533, 0.005181517, 0.0056053917, 0.0060488326, 0.006512091, 0.00699541, 0.0074990317, 0.008023192, 0.008568125, 0.009134057, 0.009721218, 0.010329823, 0.010960094, 0.011612245, 0.012286487, 0.012983031, 0.013702081, 0.014443844, 0.015208514, 0.015996292, 0.016807375, 0.017641952, 0.018500218, 0.019382361, 0.020288562, 0.02121901, 0.022173883, 0.023153365, 0.02415763, 0.025186857, 0.026241222, 0.027320892, 0.028426038, 0.029556843, 0.03071345, 0.03189604, 0.033104774, 0.03433981, 0.035601325, 0.036889452, 0.038204376, 0.039546248, 0.04091521, 0.042311423, 0.043735042, 0.045186214, 0.046665095, 0.048171833, 0.049706575, 0.051269468, 0.052860655, 0.05448028, 0.056128494, 0.057805434, 0.05951124, 0.06124607, 0.06301003, 0.06480328, 0.06662595, 0.06847818, 0.07036011, 0.07227186, 0.07421358, 0.07618539, 0.07818743, 0.08021983, 0.082282715, 0.084376216, 0.086500466, 0.088655606, 0.09084173, 0.09305898, 0.095307484, 0.09758736, 0.09989874, 0.10224175, 0.10461649, 0.10702311, 0.10946172, 0.111932434, 0.11443538, 0.116970696, 0.11953845, 0.12213881, 0.12477186, 0.12743773, 0.13013652, 0.13286836, 0.13563336, 0.13843165, 0.14126332, 0.1441285, 0.1470273, 0.14995982, 0.15292618, 0.1559265, 0.15896086, 0.16202943, 0.16513224, 0.16826946, 0.17144115, 0.17464745, 0.17788847, 0.1811643, 0.18447503, 0.1878208, 0.19120172, 0.19461787, 0.19806935, 0.2015563, 0.20507877, 0.2086369, 0.21223079, 0.21586053, 0.21952623, 0.22322798, 0.22696589, 0.23074007, 0.23455065, 0.23839766, 0.2422812, 0.2462014, 0.25015837, 0.25415218, 0.2581829, 0.26225072, 0.26635566, 0.27049786, 0.27467737, 0.27889434, 0.2831488, 0.2874409, 0.2917707, 0.29613832, 0.30054384, 0.30498737, 0.30946895, 0.31398875, 0.31854683, 0.32314324, 0.32777813, 0.33245158, 0.33716366, 0.34191445, 0.3467041, 0.3515327, 0.35640025, 0.36130688, 0.3662527, 0.37123778, 0.37626222, 0.3813261, 0.38642952, 0.39157256, 0.3967553, 0.40197787, 0.4072403, 0.4125427, 0.41788515, 0.42326775, 0.42869055, 0.4341537, 0.43965724, 0.44520125, 0.45078585, 0.45641106, 0.46207705, 0.46778384, 0.47353154, 0.47932023, 0.48514998, 0.4910209, 0.49693304, 0.5028866, 0.50888145, 0.5149178, 0.5209957, 0.52711535, 0.5332766, 0.5394797, 0.5457247, 0.5520116, 0.5583406, 0.5647117, 0.57112503, 0.57758063, 0.5840786, 0.590619, 0.597202, 0.60382754, 0.61049575, 0.61720675, 0.62396055, 0.63075733, 0.637597, 0.6444799, 0.6514058, 0.65837497, 0.66538745, 0.67244333, 0.6795426, 0.68668544, 0.69387203, 0.70110214, 0.70837605, 0.7156938, 0.72305536, 0.730461, 0.7379107, 0.7454045, 0.75294244, 0.76052475, 0.7681514, 0.77582246, 0.78353804, 0.79129815, 0.79910296, 0.8069525, 0.8148468, 0.822786, 0.8307701, 0.83879924, 0.84687346, 0.8549928, 0.8631574, 0.87136734, 0.8796226, 0.8879232, 0.89626956, 0.90466136, 0.913099, 0.92158204, 0.93011117, 0.9386859, 0.9473069, 0.9559735, 0.9646866, 0.9734455, 0.98225087, 0.9911022, 1.0]`,
160s  right: `[0.0, 0.000303527, 0.000607054, 0.00091058103, 0.001214108, 0.001517635, 0.0018211621, 0.002124689, 0.002428216, 0.002731743, 0.00303527, 0.0033465356, 0.003676507, 0.004024717, 0.004391442, 0.0047769533, 0.005181517, 0.0056053917, 0.0060488326, 0.006512091, 0.00699541, 0.0074990317, 0.008023192, 0.008568125, 0.00913406, 0.009721218, 0.010329823, 0.010960094, 0.011612247, 0.01228649, 0.012983033, 0.013702083, 0.014443844, 0.015208514, 0.015996292, 0.016807377, 0.017641956, 0.018500222, 0.019382361, 0.020288562, 0.02121901, 0.022173883, 0.023153368, 0.024157634, 0.025186861, 0.026241222, 0.027320892, 0.028426038, 0.029556837, 0.03071345, 0.03189604, 0.033104774, 0.03433981, 0.035601318, 0.036889452, 0.038204376, 0.039546236, 0.0409152, 0.04231141, 0.043735027, 0.045186214, 0.046665095, 0.048171833, 0.049706575, 0.051269468, 0.052860655, 0.05448028, 0.056128494, 0.057805434, 0.05951124, 0.061246056, 0.06301002, 0.064803265, 0.06662595, 0.06847818, 0.07036011, 0.07227186, 0.07421358, 0.07618539, 0.07818743, 0.08021983, 0.082282715, 0.084376216, 0.086500466, 0.08865559, 0.09084171, 0.093058966, 0.095307484, 0.09758736, 0.09989874, 0.10224175, 0.10461649, 0.10702311, 0.10946172, 0.111932434, 0.11443538, 0.116970696, 0.11953845, 0.1221388, 0.12477184, 0.1274377, 0.13013649, 0.13286836, 0.13563336, 0.13843165, 0.14126332, 0.1441285, 0.1470273, 0.14995982, 0.15292618, 0.1559265, 0.15896086, 0.1620294, 0.16513222, 0.16826943, 0.17144115, 0.17464745, 0.17788847, 0.1811643, 0.18447503, 0.1878208, 0.19120172, 0.19461787, 0.19806935, 0.2015563, 0.20507877, 0.2086369, 0.21223079, 0.21586053, 0.21952623, 0.22322798, 0.22696589, 0.23074007, 0.2345506, 0.23839758, 0.24228114, 0.2462014, 0.25015837, 0.25415218, 0.2581829, 0.26225072, 0.26635566, 0.27049786, 0.27467737, 0.27889434, 0.2831488, 0.2874409, 0.2917707, 0.29613832, 0.30054384, 0.30498737, 0.30946895, 0.31398875, 0.31854683, 0.32314324, 0.32777813, 0.33245158, 0.33716366, 0.34191445, 0.3467041, 0.35153264, 0.35640016, 0.3613068, 0.3662526, 0.37123778, 0.37626222, 0.3813261, 0.38642952, 0.39157256, 0.3967553, 0.40197787, 0.4072403, 0.4125427, 0.41788515, 0.42326775, 0.42869055, 0.4341537, 0.43965724, 0.44520125, 0.45078585, 0.45641106, 0.46207705, 0.46778384, 0.47353154, 0.47932023, 0.48514998, 0.4910209, 0.49693304, 0.5028865, 0.50888133, 0.5149177, 0.5209957, 0.5271152, 0.5332766, 0.5394797, 0.5457247, 0.5520116, 0.5583406, 0.5647117, 0.57112503, 0.57758063, 0.5840786, 0.590619, 0.597202, 0.60382754, 0.61049575, 0.61720675, 0.62396055, 0.63075733, 0.637597, 0.6444799, 0.6514058, 0.65837497, 0.66538745, 0.67244333, 0.6795426, 0.68668544, 0.6938719, 0.701102, 0.70837593, 0.7156938, 0.72305536, 0.730461, 0.7379107, 0.7454045, 0.75294244, 0.76052475, 0.7681514, 0.77582246, 0.78353804, 0.79129815, 0.79910296, 0.8069525, 0.8148468, 0.822786, 0.8307701, 0.83879924, 0.84687346, 0.8549928, 0.8631574, 0.87136734, 0.8796226, 0.8879233, 0.89626956, 0.90466136, 0.9130988, 0.92158204, 0.93011105, 0.938686, 0.9473069, 0.9559737, 0.9646866, 0.9734456, 0.98225087, 0.9911024, 1.0]`', src/lib.rs:301:9
160s stack backtrace:
160s    0: rust_begin_unwind
160s              at /usr/src/rustc-1.66.0/library/std/src/panicking.rs:575:5
160s    1: core::panicking::panic_fmt
160s              at /usr/src/rustc-1.66.0/library/core/src/panicking.rs:65:14
160s    2: core::panicking::assert_failed_inner
160s    3: core::panicking::assert_failed
160s              at /usr/src/rustc-1.66.0/library/core/src/panicking.rs:203:5
160s    4: fast_srgb8::tests::test_from_srgb8
160s              at ./src/lib.rs:301:9
160s    5: fast_srgb8::tests::test_from_srgb8::{{closure}}
160s              at ./src/lib.rs:299:5
160s    6: core::ops::function::FnOnce::call_once
160s              at /usr/src/rustc-1.66.0/library/core/src/ops/function.rs:251:5
160s    7: core::ops::function::FnOnce::call_once
160s              at /usr/src/rustc-1.66.0/library/core/src/ops/function.rs:251:5
160s note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[thomcc]

That test is likely a harmless failure. It does mean the from_srgb8 function won't return bit-identical results with a naïve implementation, but there's likely no way we can guarantee that anyway because of how passing/returning floats via the x87 stack works.

[jonassmedegaard]

Thanks for the confirmation - I'll simply skip that test, then.

By the way, in case you care: I am packaging this crate officially for Debian - Develpers' dashboard and package list

[thomcc]

Neat, feel free to let me know if there are any issues.

[jonassmedegaard]

I sure will

[thomcc]

Note: This is pretty long-winded and really is just background for a few questions I have -- skip to the end if this is too much right now (no worries). I'm interested in figuring out the cause of the failure (but don't have easy 32bit x86 access, and want to replicate it exactly when I do). Anyway, it has nothing to do with this project, the test is still ignorable if it fails. It's just possibly relevant for rust-lang/rust.

So, while I stand by my earlier assessment, it's actually kinda surprising that this fails only on the i686-unknown-linux-gnu build. You can ignore this if you don't have time, but there's some relevant ongoing work in the Rust project (I'm a rust-lang/libs team member) around IEEE compliance (https://hackmd.io/@CV5q1SRASEuY8WfOgd_3iQ/Bk5TnD4c3, although you don't have to read it), and I'd like to make sure this isn't a surprising counterexample to our best known data.

To be clear, the test is not really robust, and is mostly written to catch a case where I break something locally and don't recompute the table. The most likely reason it's wrong is that the test side calls (after a few layers) the system libm's pow function, which can return a slightly different value on different systems, and the test uses an exact equality check. It should probably use a specific pow implementation, an approximate equality check, or something like this (not doing this was semi-intentional, but only for dubious reasons). The only wrinkle here is that every other arch apparently passed(?), even tho they're presumably all using the same libm¹

The other option is that pow is no different, but the other floating point operations return slightly different results. On 32-bit x86 targets where SSE2 is not known to be available at compile time, this is the case². This is what I had thought was happening initially, because I didn't read carefully and misinterpreted what i386 meant (I should have -- Debian is my favorite distro to do any multi-arch stuff on, it's great for cross-compiles).

The log says i686-unknown-linux-gnu tho, which should have SSE2 on everywhere (by default), and on 32-bit x86 targets with SSE2 statically available, our understanding is that LLVM will be IEEE-754 compliant, outside of edge cases involving returning NaNs³. It's not impossible for Debian to change the default features for a target (other distros have done this), which would explain this (I think Rust's understanding of i686 is slightly ahead of what real i686 machines can run, so perhaps this is why).

Anyway, assuming it's the normal i686-unknown-linux-gnu target, that's tier-1 so it'd be good to know if it misbehaves more than we believe (the discussion was whether or not it could be tier 1 if its floating point implementation is very non-compliant. It's known to be a little non-compliant, but only in edge cases around NaNs³).

---

Anyway, that's all background to a few questions I'd like to ask you, if you know. No worries if you don't. The third question is the one I care the most about:

1. If you know, did this test fail on more targets than x86? If so then there's no real concern, almost certainly the pow (I mean... I should still fix the test, of course, but... I'll get to it).

2. Is the libm you're using just glibc's? I can take a look at it's pow code for 64-bit floats then (an important target for sure, so it wouldn't be that odd -- maybe they do some rounds of newtons method using extended precision or something).

3. Third, are the compilation flags for the i686-unknown-linux-gnu target the typical ones? Like, if Debian is turning off SSE2 or something, this would also explain things -- I know other distro's tweak the default target features (and while we'd rather they didn't, eh), so this isn't unheard of.

4. This is very wishy-washy so no worries if you don't have an answer, but perhaps such failures in floating point are common on 32-bit x86, and if so, do you have any gut feeling as to whether or not they usually involve calls to special functions? (No worries if you don't pay much attention to what went wrong, it's a long shot of a question)

I think that's it. Honestly, it's very likely that the pow implementation is slightly different on 32-bit x86 and nothing else. The test shouldn't depend on it exactly either way.

Footnotes

1. I would expect either pow to be largely the same for the same libm on different arches, or for it to be different on several of them. For example it might be different because of using an extended precision float to do a couple of newton iterations to improve accuracy at the end, but doing that on 32-bit x86 and not x86_64 is a little surprising, and the powerpc targets also have their own extended precision floats.... ↩

2. It will compute using the x87 operations, without rounding to 64-bits for each one. If multiple operations are performed, then they won't have the same intermediate rounding behavior. ↩

3. This doesn't apply to this code, but specifically the NaN payload bits are not always preserved when returning floats from functions on 32-bit x86, even if SSE2 is present. IEEE754 wants passing/returning/copying a float (the copy operation according to IEEE754-2019) to fully preserve every bit, even for NaN. The value of NaN payload bits are a problem for Wasm as well, and hit some implementation bugs in LLVM, so it's very plausible that this won't be part of the subset of IEEE754 that Rust cares about. ↩ ↩²

[jonassmedegaard]

The log says i686-unknown-linux-gnu tho, which should have SSE2 on everywhere

Debian architecture i386 does not include `SSE2.

If you know, did this test fail on more targets than x86? If so then there's no real concern, almost certainly the pow (I mean... I should still fix the test, of course, but... I'll get to it).

At the time this was reported, only CI tests for i386 failed - all other architectures doing CI testing succeeded.
CI testing logs are not kept for long, however, so I doubt they are still available since I sloppily disabled the test across the board (simply because that was easier foe me than declaring CI tests architecture-specific).

Is the libm you're using just glibc's? I can take a look at it's pow code for 64-bit floats then (an important target for sure, so it wouldn't be that odd -- maybe they do some rounds of newtons method using extended precision or something).

Yes, I am pretty sure that on Debian without overriding defaults (which I don't for this packaging) glibc is used.

Third, are the compilation flags for the i686-unknown-linux-gnu target the typical ones? Like, if Debian is turning off SSE2 or something, this would also explain things -- I know other distro's tweak the default target features (and while we'd rather they didn't, eh), so this isn't unheard of.

As per my initial note above, I would indeed expect SSE2 to not be available on the Debian i386 target.

Perhaps you can spot some concrete evidence from the logs of the Debian machinery.

This is very wishy-washy so no worries if you don't have an answer, but perhaps such failures in floating point are common on 32-bit x86, and if so, do you have any gut feeling as to whether or not they usually involve calls to special functions? (No worries if you don't pay much attention to what went wrong, it's a long shot of a question)

Sorry, I don't know such details.

[thomcc]

(Sorry for the delay in responding, been swamped at $DAYJOB)

Debian architecture i386 does not include `SSE2.

Thank you, this answers my questions.

And disabling that test across the board is totally reasonable -- probably the right call (the test is sloppily written, and intended to catch my own mistakes rather than anybody elses).

Thanks for getting back to me, it's cool to see that Debian runs package tests.

[thomcc]

Fat fingered the close button, my bad. (This isn't closed until I fix the test)