Test failures on Fedora

[cuviper]

I got a few failures when I tried to enable testing in Fedora's rayon packages. I'll list them here, and we can break them into separate issues if necessary.

• rayon-core/tests/stack_overflow_crash.rs tries to force a stack overflow and fails. It's trying to do this fairly precisely with large data on the stack, rather than something like infinite recursion, so we can verify it also passes when the stack is larger. In Fedora, we force optimization flags, and this causes that unused stack data to be optimized away.

  • Fixed by Improve rayon-core/tests/stack_overflow_crash.rs #1009

• Both of Fedora's 32-bit platforms, i686 and armv7hl, get stuck on the octillion tests -- they're still running after a few hours here...

  • Ignored in Use wrapping addition for JEC #800 commit 5af9d7e

     Running `/builddir/build/BUILD/rayon-1.0.2/target/release/deps/octillion-4b3d72e9b100245b`
running 4 tests
test find_first_octillion ... ok
test find_last_octillion_flat ... test find_last_octillion_flat has been running for over 60 seconds
test find_last_octillion ... test find_last_octillion has been running for over 60 seconds
test find_first_octillion_flat ... test find_first_octillion_flat has been running for over 60 seconds

• ppc64 and ppc64le both failed range::test_usize_i64_overflow. Since other 64-bit arches passed, and there's nothing else arch-specific about this test, I worry it may be a codegen issue.
  • Fixed since LLVM 12 by llvm/llvm-project@f6515b0

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `None`,
 right: `Some(9223372036854775806)`', src/range.rs:275:21
test range::test_usize_i64_overflow ... FAILED

[cuviper]

Both of Fedora's 32-bit platforms, i686 and armv7hl, get stuck on the octillion tests

This appears to be a limitation of mod find_first_last working with best_found: &AtomicUsize. We "split" that usize bitwise when the find consumer splits, but we only have 32-bits to play with here. After that, we can't tell where we are in the iterator, so we have to compare everything within the same best_found split. With 10²⁷ total items, dividing into 2³² chunks still leaves a lot of work to do in that given "best" chunk.

It's a silly test anyway -- maybe we should just limit it to 64-bit targets. It would be nice if find_first/last could better refine this best_found though...

[decathorpe]

Coming back to this after updating the Fedora package for the rayon-core crate to v1.10.2: I re-enabled the test suite and all tests passed across all our supported architectures. Thanks! :)