GVN does not account for implicit retags during assignment

Open
  • Is something wrong?
#165,327 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
compilers

Research direction

Reproduce the snippet in the issue under Miri with -Zmir-opt-level=1 -Zmir-enable-passes=+GVN -Zmiri-tree-borrows to confirm the Tree Borrows error at borrow_field_a. The open question is whether the fix belongs in MIR semantics for implicit retags or in the GVN pass, and the maintainers have not decided that. Done means the reproducer passes Miri under both Stacked Borrows and Tree Borrows, which needs maintainer agreement on the approach first.

Written by the indexing model from the issue text.

Description

A-mir-opt A-mir-opt-GVN I-miscompile I-unsound P-medium T-compiler

This code is fine under our current aliasing models, but GVN optimizes it into something that has UB under both Stacked Borrows and Tree Borrows:

fn main() {
    struct Foo {
        a: String,
        b: Vec<u32>,
    }

    unsafe fn borrow_field_a<'a>(this: *mut Foo) -> &'a mut String {
        &mut (*this).a
    }

    unsafe fn borrow_field_b<'a>(this: *mut Foo) -> &'a mut Vec<u32> {
        &mut (*this).b
    }

    let mut foo = Foo { a: "hello".into(), b: vec![0, 1, 2] };

    let ptr = &mut foo as *mut Foo;

    let a = unsafe { borrow_field_a(ptr) };
    let b = unsafe { borrow_field_b(ptr) };
    b.push(4);
    a.push_str(" world");
    assert_eq!(format!("{:?} {:?}", a, b), r#""hello world" [0, 1, 2, 4]"#);
}

Running this in Miri with -Zmir-opt-level=1 -Zmir-enable-passes=+GVN -Zmiri-tree-borrows reports UB:

error: Undefined Behavior: reborrow through <605> at alloc406[0x0] is forbidden
  --> /opt/compiler-explorer/rust-miri-nightly/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2918:70
   |
   = note: Undefined Behavior occurred here
  ::: /opt/compiler-explorer/rust-miri-nightly/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2924:0
   |
   = note: in this macro invocation
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Tree Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/tree-borrows.md for further information
   = help: the accessed tag <605> has state Disabled which forbids this reborrow (acting as a child read access)
help: the accessed tag <605> was created here, in the initial state Reserved
  --> <source>:19:22
   |
19 |     let a = unsafe { borrow_field_a(ptr) };
   |                      ^^^^^^^^^^^^^^^^^^^
help: the accessed tag <605> later transitioned to Disabled due to a foreign write access at offsets [0x0..0x8]
  --> <source>:22:5
   |
22 |     a.push_str(" world");
   |     ^^^^^^^^^^^^^^^^^^^^

https://rust.godbolt.org/z/z5nqqhfxn

Cc @rust-lang/wg-mir-opt
I'm not sure if the fix here is a change in MIR semantics or a change in GVN, but something surely needs to be fixed.

Dominant language
Rust
Stars
121k
Forks
17.3k
Avg merge
2d 21h
Merged PRs (30d)
531

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-lang/rust

All issues in rust-lang/rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.