LLVM `nocapture` attribute is used incorrectly

[tmiasko]

The implementation of indirect_pass_mode contains following code:

        // For non-immediate arguments the callee gets its own copy of
        // the value on the stack, so there are no aliases. It's also
        // program-invisible so can't possibly capture
        attrs
            .set(ArgAttribute::NoAlias)
            .set(ArgAttribute::NoCapture)
            .set(ArgAttribute::NonNull)
            .set(ArgAttribute::NoUndef);

The claim that a callee can't possibly capture the argument is incorrect. The callee can obtain the address of the parameter and use it in arbitrary way. Consider the following example. In the call to f, b is an address of a static S, whose memory should be disjoint from parameter a. Consequently f should return false:

static S: [u32; 64]  = [0; 64];

#[inline(never)]
pub fn f(a: [u32; 64], b: usize) -> bool {
    &a as *const _ as usize == b
}

fn main() {
    assert!(!f(S, &S as *const _ as usize));
}

$ rustc a.rs -Copt-level=0 && ./a
$ rustc a.rs -Copt-level=1 && ./a

thread 'main' panicked at a.rs:9:5:
assertion failed: !f(S, &S as *const _ as usize)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[hanna-kruppe]

This example depends on the pointer address. But recently LLVM has started separating “address capture” from “provenance capture” — I think it’s correct to say the latter isn’t captured here, meaning that any pointer to a constructed in f should be considered dangling (by Rust semantics) after the corresponding call to f returns. cc @nikic

[nikic]

Yes, I believe making these captures(address) would be legal. (This is LLVM 21 only though.)

[jieyouxu]

(Tagging this as unsound but feel free to readjust/reprioritize)

[apiraino]

Is this something that can be taken care upon upgrading to LLVM 21 or better discuss this earlier?

I've tried digging a bit but I'm a bit unsure about the details: is indirect_pass_mode nightly-only? A git blame seem to indicate that that code was touched years ago (so I think it's ok to not consider this a regression).

thanks

[nikic]

This issue isn't nightly only. In fact, it has been known for a long time (I'm pretty sure we already have an issue for it somewhere, but I couldn't find it).

As far as I know, the only thing this affects is ability to observe whether an intermediate copy has been optimized away, it doesn't allow you to do anything beyond that (like modify the memory of the original, as that would be UB due to reference semantics).