Ret from for-loop block sometimes generated bad LLVM bitcode #2142
Labels
Milestone
Comments
ghost
assigned 
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 22, 2022
Make allow_data_races_* public and use it during EnvVars::cleanup Fixes rust-lang/miri#2020 I've tried for hours now to come up with a test case for this ICE with no luck. I suspect there's something about the way the data race detection works under these conditions that I just don't understand 😩. But I tried this change out on a handful of crates and I don't see any more ICEs of this form. For whatever reason it seems like `bastion==0.4.5` is a good way to run into this, with the flags ``` MIRIFLAGS="-Zmiri-tag-raw-pointers -Zmiri-panic-on-unsupported -Zmiri-disable-isolation" cargo +miri miri test --no-fail-fast --doc ``` I think all the cases I've run into with this involve both `-Zmiri-panic-on-unsupported` and `-Zmiri-tag-raw-pointers`, so it could be that the combination of an unexpected panic and a machine halt is required.
celinval
pushed a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
Kobzol
pushed a commit
to Kobzol/rust
that referenced
this issue
Dec 30, 2024
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is somewhat subtle, in that I haven't been able to reproduce it in small toy programs, but I had to make several changes to loops to make things compile as part of the switch to new-style loops (#1619). The error you get is about an unterminated block.
See for example
c902eaf#L1R92
c902eaf#L49R1649
The text was updated successfully, but these errors were encountered: