-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Fix a couple ICEs in the new CastKind::Transmute
code
#110021
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Oh, convenient, this accidentally made a repro of #109992 too 🙃 |
CastKind::Transmute
sizes in a better wayCastKind::Transmute
code
Some(OperandRef::new_zst(bx, cast).val) | ||
} | ||
(ScalarOrZst::Scalar(in_scalar), ScalarOrZst::Scalar(out_scalar)) | ||
if in_scalar.size(self.cx) == out_scalar.size(self.cx) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this check necessary?
For pairs you need to check the inner size because matching size of the whole pair doesn't necessarily imply matching sizes of elements... But surely the operand.layout.size != cast.size
check is sufficient for scalars? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good call. Let me give that a shot -- might allow deleting more code too...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this check, but ScalarOrZst::size
is still needed elsewhere, so I couldn't remove more than that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, no, vectors. Without this check <4 x i64>
to <8 x f32>
trips the later debug-assert.
I suppose I could hypothetically bitcast
that anyway, but I'm not doing that this PR.
Added some codegen tests for vectors so that when future me breaks this while running --keep-stage-std
again, I'll notice without CI 😬
565e3db
to
621417b
Compare
@bors r+ |
📌 Commit 621417bf7d51f9345d4e0669a150189e50a231db has been approved by It is now in the queue for this repository. |
⌛ Testing commit 621417bf7d51f9345d4e0669a150189e50a231db with merge 7deb56e0f1c0ca611132e8f7c025896c2398291e... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
r=me |
I'd forgotten I made that test file only-64bit instead of my usual only-x86_64 🤦 @bors r=compiler-errors |
Rollup of 6 pull requests Successful merges: - rust-lang#109724 (prioritize param env candidates if they don't guide type inference) - rust-lang#110021 (Fix a couple ICEs in the new `CastKind::Transmute` code) - rust-lang#110044 (Avoid some manual slice length calculation) - rust-lang#110115 (compiletest: Use remap-path-prefix only in CI) - rust-lang#110121 (Fix `x check --stage 1` when download-rustc is enabled) - rust-lang#110124 (Some clippy fixes in the compiler) Failed merges: - rust-lang#109752 (Stall auto trait assembly in new solver for int/float vars) r? `@ghost` `@rustbot` modify labels: rollup
…ompiler-errors Add a distinct `OperandValue::ZeroSized` variant for ZSTs These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than `Aggregate`s sometimes being `Immediates` (after all, I previously got that wrong and caused rust-lang#109992). As a minor bonus, it means we don't need to generate poison LLVM values for ZSTs to pass around in `OperandValue::Immediate`s. Inspired by rust-lang#110021 (comment), so r? `@compiler-errors`
…ompiler-errors Add a distinct `OperandValue::ZeroSized` variant for ZSTs These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than `Aggregate`s sometimes being `Immediates` (after all, I previously got that wrong and caused rust-lang#109992). As a minor bonus, it means we don't need to generate poison LLVM values for ZSTs to pass around in `OperandValue::Immediate`s. Inspired by rust-lang#110021 (comment), so r? ``@compiler-errors``
…ompiler-errors Add a distinct `OperandValue::ZeroSized` variant for ZSTs These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than `Aggregate`s sometimes being `Immediates` (after all, I previously got that wrong and caused rust-lang#109992). As a minor bonus, it means we don't need to generate poison LLVM values for ZSTs to pass around in `OperandValue::Immediate`s. Inspired by rust-lang#110021 (comment), so r? ```@compiler-errors```
…ompiler-errors Add a distinct `OperandValue::ZeroSized` variant for ZSTs These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than `Aggregate`s sometimes being `Immediates` (after all, I previously got that wrong and caused rust-lang#109992). As a minor bonus, it means we don't need to generate poison LLVM values for ZSTs to pass around in `OperandValue::Immediate`s. Inspired by rust-lang#110021 (comment), so r? `@compiler-errors`
Check the sizes of the immediates, rather than the overall types, when deciding whether we can convert types without going through memory.
Fixes #110005
Fixes #109992
Fixes #110032
cc @matthiaskrgr