Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

miri_to_const bug on big-endian targets #11488

Closed
RalfJung opened this issue Sep 12, 2023 · 7 comments · Fixed by #11565
Closed

miri_to_const bug on big-endian targets #11488

RalfJung opened this issue Sep 12, 2023 · 7 comments · Fixed by #11565

Comments

@RalfJung
Copy link
Member

RalfJung commented Sep 12, 2023

Description

I just noticed the miri_to_const function. This seems to duplicate a bunch of the logic in try_destructure_mir_constant_for_diagnostics, maybe it would make sense to fully migrate to that query instead?

In particular the current logic is partially wrong: it has support for ConstValue::Indirect arrays of floats. However, using from_le_bytes to convert interpreter floats to an f32 is going to go wrong on big-endian targets. You need to take into account the endianess of the current compiler session. Or ideally you just use all the functions that already exist in rustc to work with interpreter data, e.g. Allocation::read_scalar.

(Also, we are using "Miri" as the name for the tool these days, so the function is somewhat misnamed. This is really just converting a MIR constant into a Clippy constant.)

Version

No response

Additional Labels

No response

@RalfJung
Copy link
Member Author

RalfJung commented Sep 12, 2023

Ah, in field_of_struct you are using try_destructure_mir_constant_for_diagnostics, nice. So it's really just that float array logic that should be changed to either read_scalar or try_destructure_mir_constant_for_diagnostics.

@RalfJung
Copy link
Member Author

Oh, also that code is completely ignoring the offset in ConstValue::ByRef, so it could actually end up loading the wrong data from memory.

@Jarcho
Copy link
Contributor

Jarcho commented Sep 15, 2023

The scalar floats are also read wrong when cross compiling between big and little endian targets, right?

@RalfJung
Copy link
Member Author

RalfJung commented Sep 15, 2023

Yes, when I said they are wrong on big-endian targets I meant they are wrong whenever the --target is big-endian. The host endianess does not matter.

(Having a big-endian host and a little-endian target should work with the current code, though.)

@RalfJung
Copy link
Member Author

Note that there were some recent rustc changes here, so if code this is now changed on the clippy side it would probably lead to conflicts. We should await the next rustc-to-clippy sync.

@Jarcho
Copy link
Contributor

Jarcho commented Sep 15, 2023

I was referring to conversion a little above that.

ty::Float(FloatTy::F32) => Some(Constant::F32(f32::from_bits(
    int.try_into().expect("invalid f32 bit representation"),
))),
ty::Float(FloatTy::F64) => Some(Constant::F64(f64::from_bits(
    int.try_into().expect("invalid f64 bit representation"),
))),

@RalfJung
Copy link
Member Author

That should be fine, ScalarInt is always using host endianess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants