Miscompilation, exposed provenance not picked up correctly

[orlp]

I tried this code:

#[inline(never)]
fn test(x: &i32) {
    let addr = (x as *const i32).wrapping_sub(1).addr();
    let p: *mut i32 = std::ptr::with_exposed_provenance_mut(addr);
    unsafe { *p += 1 };
}

fn main() {
    let mut arr = [0, 0];
    let [a, b] = arr.get_disjoint_mut([0, 1]).unwrap();
    (a as *mut i32).expose_provenance();
    test(&b);
    dbg!(arr);
}

I expected to see this happen: I'd expect to see [1, 0] printed.

Instead, this happened: in debug mode [1, 0] gets printed, but in release mode [0, 0] gets printed.

Occurs on 1.95 stable and latest nightly.

Found by @ruriww.

[orlp]

I guess the question is, is the address of a pointer outside its provenance defined? It compiles correctly with (x as *const i32).addr() - 4 instead of (x as *const i32).wrapping_sub(1).addr().

The Rust docs does guarantee that wrapping_sub can temporarily go out of the provenance and go back in, but I'm not sure if any guarantees are made about the address you would get from an out-of-provenance pointer.

[RalfJung]

Yes the address of a pointer is always well-defined and entirely unaffected by its provenance. This is an instance of the known LLVM problems around provenance.

Maybe we should compile addr() to ptrtoint to partially mitigate this for now? @nikic

[nikic]

@RalfJung We already do that. We don't actually use ptrtoaddr for addr().

The issue in this sample is the usual int2ptr(ptr2int(x)) one. (Which, I think, is the first one we should address after byte type implementation is complete.)

[RalfJung]

Oh right... we implement it as a transmute but we actually lower all ptr-to-int transmute to casts under the hood, but even that is not enough. Not much we can do about it at the moment then, just wait for byte type to progress further.

[orlp]

If this is "the usual" case this issue can probably be closed as a dupe. Is there a canonical/tracking issue @nikic ?

[nikic]

The corresponding LLVM issue is llvm/llvm-project#33896.

[RalfJung]

On the Rust side we have #147538, so closing as a duplicate of that.