-
Notifications
You must be signed in to change notification settings - Fork 308
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
Report UB instead of ICEing when SIMD operands have incompatible size #3076
Comments
We generally ICE when intrinsics are used the wrong way. I don't think we should make an exception for SIMD intrinsics.
|
Hm. My concern is that we attach this text to an ICE:
Which is not appropriate if the ICE is actually user error. |
Yeah, that text is wrong when intrinsics are involved (and possibly with other internal features as well), see e.g. this example. I'm fairly sure it's also possible to ICE rustc by misusing intrinsics, so this is not really a Miri issue. |
Here's a rustc ICE that's not-a-bug due to being related to intrinsics. We should clarify the message printed on an ICE (but getting access to enough state to figure out if any internal feature was enabled might be tricky). But that's a rustc issue, not a Miri issue. |
This now prints
FWIW with a regular rustc build it doesn't even ICE, it hits an LLVM assertion. So I don't think there is anything else we want to do in the Miri side here. rust-lang/rust#116217 tracks the ICE message. |
Thanks! I agree that making this an internal feature is a good improvement. |
In a lot of our SIMD intrinsics, we assert that operands which must be equal size are equal size. Such a situation can arise because of an implementation mistake which would justify an ICE, but they can also arise if someone tries to declare their own LLVM intrinsics and gets it wrong. For example:
This should report UB instead of ICEing.
The text was updated successfully, but these errors were encountered: