-
Notifications
You must be signed in to change notification settings - Fork 13.3k
enums with repr(align) generate Scalar layout with padding (ICE: miri: field access on non aggregate <uninitialized> ) #96185
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Looks like it tries to access the discriminant (field 0 of
The case does not apply because |
Oh, turns out codegen uses the same logic:
So I think a similar bug can somehow be triggered in codegen. I am just not sure how to make it call |
I am still missing something, the bug doesn't reproduce as often as it should... e.g., this one doesn't ICE #[allow(dead_code)]
#[repr(align(8))]
enum Aligned {
Zero = 0,
One = 1,
}
fn main() {
let aligned = Aligned::Zero;
let _x = match aligned { Aligned::Zero => 0, Aligned::One => 1 };
} but this one does #[allow(dead_code)]
#[repr(align(8))]
enum Aligned {
Zero = 0,
One = 1,
}
fn id(a: Aligned) -> Aligned { a }
fn main() {
let aligned = id(Aligned::Zero);
let _x = match aligned { Aligned::Zero => 0, Aligned::One => 1 };
} Also I noticed that this type #[repr(align(8))]
struct Aligned(NonZeroU8); has |
FWIW, if I put this kind of sanity check
also into Miri, things explode spectacularly. This type from memchr enum Shift {
Small { period: usize },
Large { shift: usize },
} ends up with a EDIT: Also, just fixing the logic in |
Not really a why in the sense you're asking for, but the layout computation makes the struct decision right here: rust/compiler/rustc_middle/src/ty/layout.rs Line 486 in e2661ba
For fieldless enums, rust/compiler/rustc_middle/src/ty/layout.rs Line 1327 in e2661ba
|
So this is just a bug in That would be a big relief. ;) |
I made that a separate issue: #96221. So this issue now is about some enums violating the invariant that |
I am not sure where is the right place though... However, I also cannot see any code in the enum path that would take into account |
This is quite interesting, and I am not sure what to do.
It is impossible to satisfy both of these constraints together. @oli-obk @eddyb any ideas for what to do here? |
(Digging a bit deeper) it's not [just] about having explicit discriminants, but rather that enums can be the input to a cast and cast values are expected to be represented as immediates. Allowing |
tighten sanity checks around Scalar and ScalarPair While investigating rust-lang#96185 I noticed codegen has tighter sanity checks here than Miri does, so I added some more assertions. Strangely, some of them fail, so I also needed to add a HACK... that is probably worth looking into. This does not fix that issue, but it changes the ICE messages, making it quite clear that we have a scalar whose size is not the same as that of the surrounding layout. r? `@oli-obk`
FWIW, here's basically the same bug during CTFE, though for some reason it doesn't cause an ICE: #[allow(dead_code)]
#[repr(align(8))]
enum Aligned {
Zero = 0,
One = 1,
}
const X: () = {
let aligned = Aligned::Zero;
let _val = &(aligned as u8);
}; So we can have this as a testcase in rustc. |
rustup Adds a regression test for rust-lang/rust#96185
Code
run this in miri to reproduce the ice:
Meta
rustc --version --verbose
:Error output
Backtrace
The text was updated successfully, but these errors were encountered: