optimized i686 fails primal-sieve tests

[cuviper]

Discovered in huonw/primal#37 (comment)

Code

I don't have reduced code, but the primal-sieve testsuite fails on i686-unknown-linux-gnu when compiled in --release mode, specifically on this line:
https://github.com/huonw/primal/blob/79bafd3400ecf530bea1d26db4f3854407588c2a/primal-sieve/src/sieve.rs#L769

    #[test]
    fn sum_primes() {
        let primes = Sieve::new(2_000_000);

        let mut manual_sum = 0u64;
        for p in primes.primes_from(0) {
            manual_sum += p as u64;
        }
        dbg!(manual_sum);

        let folded_sum = primes.primes_from(0).fold(0u64, |acc, p| acc + p as u64);
        let trait_sum = primes.primes_from(0).map(|p| p as u64).sum::<u64>();
        assert_eq!(manual_sum, folded_sum); // <-- FAILED
        assert_eq!(manual_sum, trait_sum);
    }

It fails when compiled from x86_64 host:

$ cd primal-sieve
$ cargo +nightly test --release --target i686-unknown-linux-gnu sum_primes

or with a native i686 host toolchain:

$cargo +nightly-i686 test --release sum_primes

I expected to see this happen: the test should pass

Instead, this happened: FAILED

---- sieve::tests::sum_primes stdout ----
[primal-sieve/src/sieve.rs:765] manual_sum = 307525716868
thread 'sieve::tests::sum_primes' panicked at 'assertion failed: `(left == right)`
  left: `307525716868`,
 right: `142913828922`', primal-sieve/src/sieve.rs:769:9

The left manual_sum is wrong, and the right folded_sum is correct. They both come from the same generated primes sieve, so that part of the code appears to have worked correctly. That leaves the difference between the for loop and the fold, and while SievePrimes does implement both next and fold, the differences are small.

The same test passes on i686 in debug mode, as well as x86_64 in debug or release.

Version it worked on

It most recently worked on: stable Rust 1.58.1

Version with regression

Both beta and nightly are failing the same way.

rustc 1.59.0-beta.8 (1945ce657 2022-02-12)
binary: rustc
commit-hash: 1945ce6579506787e0b18f0a2ea03fdb4dfc81c7
commit-date: 2022-02-12
host: x86_64-unknown-linux-gnu
release: 1.59.0-beta.8
LLVM version: 13.0.0

rustc 1.60.0-nightly (c5c610aad 2022-02-14)
binary: rustc
commit-hash: c5c610aad0a012a9228ecb83cc19e77111a52140
commit-date: 2022-02-14
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 13.0.0

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[cuviper]

I just tried armv7-unknown-linux-gnueabihf under qemu to see if the bug is a 32-bit thing, but that passes fine.

[cuviper]

It passes on i686 release with -Znew-llvm-pass-manager=no.

[nikic]

The relevant difference with the NewPM seems to be that the next() method gets inlined now.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-critical