i686-pc-windows-gnu fails to compile rsbegin

[kleisauke]

Reproducer

I tried this script:

$ curl https://sh.rustup.rs -sSf | sh -s -- -y \
    --profile minimal \
    --target i686-pc-windows-gnu \
    --default-toolchain nightly-2023-04-01 \
    --component rust-src
$ source "$HOME/.cargo/env"
$ rustc --target=i686-pc-windows-gnu --emit=obj -o rsbegin.o $(rustc --print sysroot)/lib/rustlib/src/rust/library/rtstartup/rsbegin.rs

I expected to see a successful complication.

Instead, this happened:

error: requires `panic` lang_item
  --> /home/kleisauke/.rustup/toolchains/nightly-2023-04-01-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rtstartup/rsbegin.rs:82:65
   |
82 |         __register_frame_info(&__EH_FRAME_BEGIN__ as *const u8, &mut OBJ as *mut _ as *mut u8);
   |                                                                 ^^^^^^^^

error: requires `panic` lang_item
  --> /home/kleisauke/.rustup/toolchains/nightly-2023-04-01-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rtstartup/rsbegin.rs:87:67
   |
87 |         __deregister_frame_info(&__EH_FRAME_BEGIN__ as *const u8, &mut OBJ as *mut _ as *mut u8);
   |                                                                   ^^^^^^^^

error: aborting due to 2 previous errors

Passing -Zmir-enable-passes=-CheckAlignment seems to fix this, so it looks like a possible regression introduced in #98112.

Version it worked on

It most recently worked on: rustc 1.70.0-nightly (ec2f40c 2023-03-30)

Version with regression

rustc --version --verbose:

rustc 1.70.0-nightly (5e1d3299a 2023-03-31)
binary: rustc
commit-hash: 5e1d3299a290026b85787bc9c7e72bcc53ac283f
commit-date: 2023-03-31
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

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

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[apiraino]

@rustbot label -I-prioritize +P-medium -P-high

[saethlin]

This is a nice reproducer but the priority was reduced because the use seems very niche and/or unmotivated. Can you explain why compiling just rsbegin is a requirement for you? Or what broader thing this is part of?

[bjorn3]

I was surprised that building the sysroot for i686-pc-windows-gnu doesn't hit this. rsbegin.rs and rsend.rs should be compiled as part of building the sysroot for mingw targets. Turns out we always compile them with the bootstrap compiler:

rust/src/bootstrap/compile.rs

Line 574 in 0534655

let mut cmd = Command::new(&builder.initial_rustc);

As such this issue will block bumping the bootstrap compiler to one containing #98112 and breaks local rebuilds. I'm pretty sure it will also prevent me from updating cg_clif to the latest nightly as cg_clif rebuilds rsbegin.rs and rsend.rs when targeting mingw.

The fix for this issue I think is to use addr_of_mut!() instead. Or equivalently using &raw mut, which addr_of_mut! expands to, as addr_of_mut!() is not available in these #![no_core] crates.

[kleisauke]

Indeed, this could be problematic when this regression would be present in the stage0 compiler, or when build.rustc is set to a nightly after #98112.

rust/config.example.toml

Lines 213 to 216 in 0534655

	# Instead of downloading the src/stage0.json version of the compiler
	# specified, use this rustc binary instead as the stage0 snapshot compiler.
	# If you set this, you likely want to set `cargo` as well.
	#rustc = "/path/to/rustc"

FWIW, this was originally caught here which builds these startup objects with the stage1 compiler. I've never encountered any problems with this approach until now.