Incorrect data race UB reported when mixing atomic and non-atomic accesses

[RalfJung]

Miri reports UB in this program (even with -Zmiri-fixed-schedule):

use std::sync::atomic::{AtomicUsize, Ordering};
use std::{ptr, thread};

const SIZE: usize = 256;

static mut ARRAY: [u8; SIZE] = [0; _];
// Everything strictly less than this has been initialized by the sender.
static POS: AtomicUsize = AtomicUsize::new(0);

fn main() {
    // Sender
    let th = std::thread::spawn(|| {
        for i in 0..SIZE {
            unsafe { ptr::write(&raw mut ARRAY[i], 1) };
            POS.store(i + 1, Ordering::Release);

            thread::yield_now();

            // We are the only writer, so we can do non-atomic reads as well.
            unsafe { (&raw const POS).cast::<usize>().read() };
        }
    });

    // Receiver
    loop {
        let i = POS.load(Ordering::Acquire);

        if i > 0 {
            unsafe { ptr::read(&raw const ARRAY[i - 1]) };
        }

        if i == SIZE {
            break;
        }

        thread::yield_now();
    }

    th.join().unwrap();
}

This is related to the non-atomic read; if we remove that, the program is fine.

Mixed atomic and non-atomic accesses are a Rust extension to the C++ memory model. Does our extension allow this code? I would think so; the non-atomic load is fully ordered wrt all writes to that location. Tokio certainly would like this to be allowed (tokio-rs/tokio#7712). But apparently our extension to the data race checker disallows this...

Cc @cbeuw

[RalfJung]

This is related to

    /// When a non-atomic access happens on a location that has been atomically accessed
    /// before without data race, we can determine that the non-atomic access fully happens
    /// after all the prior atomic writes so the location no longer needs to exhibit
    /// any weak memory behaviours until further atomic accesses.
    pub fn memory_accessed(&self, range: AllocRange, global: &DataRaceState) {

For non-atomic reads, that reasoning just isn't correct any more. (I think the comment was written before we allowed atomic non-atomic races.)

However, even so I would not expect removing the store buffers to ever introduce incorrect UB... somehow #4577 made it so that that can happen now, apparently.

[RalfJung]

The fix should be in the next nightly, 2025-11-03.