Suspected miscompilation using 1.63.0.0

[bugadani]

I was not able to try the following code with 1.63.0.1 due to an independent issue, but the following code compiles, then unexpectedly panics at runtime:

#[export_name = "app_main"]
pub extern "C" fn test() {
 enum E {
     A(u32),
     B(u32),
 }

 #[inline(never)]
 fn create_vec() -> Vec<E> {
     vec![E::A(1), E::A(2), E::A(3), E::A(4)]
 }

 let vec = create_vec();

 vec.iter()
     .find(|e| match e {
         E::A(id) if *id == 2 => true,
         _ => false,
     })
     .expect("Failed to find element");
}

[MabezDev]

I can't repro on 1.63.0.1, but perhaps I don't have the right setup, would it be possible to link a repo where you can reproduce?

[bugadani]

I don't have a complete setup I can share and I don't this it needs anything special. This is the exact code copied from my project (a reduced version I added to my set of compiler tests) and it's possible this was fixed in 1.63.0.1 but I could not set it up to compile my project yesterday. I'll try again with the newer compiler, thanks for the confirmation!

[bugadani]

So, unrelated issue, but this is why I can't check on 1.63.0.1:

> cargo cargo +esp c  --color=always --target="xtensa-esp32-espidf" -Z build-std="std,panic_abort" -Zbuild-std-features="panic_immediate_abort"
   Compiling std v0.0.0 (C:\Users\bugad\.rustup\toolchains\esp\lib\rustlib\src\rust\library\std)
   Compiling proc_macro v0.0.0 (C:\Users\bugad\.rustup\toolchains\esp\lib\rustlib\src\rust\library\proc_macro)
error: could not compile `std`

Caused by:
  process didn't exit successfully: `rustc --crate-name std --edition=2021 C:\Users\bugad\.rustup\toolchains\esp\lib\rustlib\src\rust\library\std\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type rlib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 -C debug-assertions=on --cfg "feature=\"panic_immediate_abort\"" -C metadata=21a6dee751f41e28 -C extra-filename=-21a6dee751f41e28 --out-dir C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps --target xtensa-esp32-espidf -Z force-unstable-if-unmarked -L dependency=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps -L dependency=C:\_Linear\sw\link-fw\main\target\debug\deps --extern alloc=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\liballoc-54d9bfc0b36f57a4.rmeta --extern cfg_if=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libcfg_if-c885e4e69dcbea08.rmeta --extern compiler_builtins=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libcompiler_builtins-a64c5dd3dea251ee.rmeta --extern core=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libcore-561a89c65f6926d6.rmeta --extern hashbrown=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libhashbrown-53f55bcd85cc22f2.rmeta --extern libc=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\liblibc-eafe857b435ec598.rmeta --extern panic_abort=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libpanic_abort-6476ed023a678d5e.rmeta --extern rustc_demangle=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\librustc_demangle-3342bad02dce6c45.rmeta --extern std_detect=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libstd_detect-fd6b2978577ed1e4.rmeta --extern unwind=C:\_Linear\sw\link-fw\main\target\xtensa-esp32-espidf\debug\deps\libunwind-5b080a5d638816c1.rmeta --cap-lints allow --cfg backtrace_in_libstd` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Works as expected on GitHub Actions, so it's either an issue in the MSVC build artifacts, or in my setup (which works as expected with 1.63.0.0)

[MabezDev]

Hmm, not too sure really, looks like an internal compiler bug maybe? I believe STATUS_ACCESS_VIOLATION is usually some kind of memory error, but I don't really know much more than that.

Any ideas @georgik?

[bugadani]

Got a hint for you guys:

If I remove codegen-units = 1 from my Cargo.toml, I don't experience the STATUS_ACCESS_VIOLATION error with 1.62.0.2.

So I'm able to use 1.63.0.2 with the following profile:

[profile.dev]
opt-level = 3
codegen-units = 16
lto = "thin"

[bugadani]

Update: I still experience this issue using 1.63.0.2.

[bugadani]

Update: I still experience this issue with 1.64.0.0

[MabezDev]

We've tracked this down internally inside LLVM. We've decided for now not to issue a point release because we already need to do some testing to transition to LLVM 15 before the next Rust release.

[MabezDev]

This should now be fixed with the 1.65.0.0 release, grab a compiler here: https://github.com/esp-rs/rust-build/releases/tag/v1.65.0.0