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

Fix ICE: inject bitcast if types mismatch for invokes/calls/stores #37112

Merged
merged 3 commits into from
Oct 17, 2016

Conversation

pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Oct 12, 2016

Fix ICE: inject bitcast if types mismatch for invokes/calls

Partial fix for #36744

@rust-highfive
Copy link
Collaborator

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

@pnkfelix
Copy link
Member Author

(oh I forgot a regression test; will put into followup commit.)

@pnkfelix
Copy link
Member Author

pnkfelix commented Oct 12, 2016

So I just realized that this fix as originally written only handles the case of calls, which does fix the specific report of #36744 but does not address the other cases that @arielb1 pointed out here: #36744 (comment)

I'm looking into generalizing it slightly now to deal with more of those.


Ideally we would handle the following cases (I will check off the ones that the PR handles as I go):

  • call arguments (when parameters have non-aggregate type)
  • stores (of any kind)
  • call arguments of aggregate type (cannot use naive bitcast...)
    • hmm, I have not yet managed to create an test case that exposes the issue I worry about here.
    • niko notes that we don't pass tuples directly in calls; we instead allocate the tuple locally and pass a pointer to it.
    • ariel notes that stores can happen via intrinsics or elsewhere when one has RVO.
  • call arguments of aggregate type (#[repr(C)] struct) to an extern "C" fn
    • this is an exception to above claim that aggregates are handled via passing pointers, and will not be handled properly in bitcasts
  • return instruction
    • It looks like this case is covered by the code I added for building store instructions

  • I'm also considering taking a different tack of extending MIR with an explicit upcast operator so that trans can remain simple. But I would be less inclined to back port a PR that takes that route.

@pnkfelix
Copy link
Member Author

While working on this PR, I realized that one flaw in this strategy is that you can not apply the LLVM bitcast instruction to aggregates. This may mean that we have other cases to handle that simply cannot be dealt with via the means used here.

@pnkfelix
Copy link
Member Author

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned Aatch Oct 13, 2016
@pnkfelix pnkfelix changed the title Fix ICE: inject bitcast if types mismatch for invokes/calls Fix ICE: inject bitcast if types mismatch for invokes/calls/stores Oct 13, 2016
@pnkfelix
Copy link
Member Author

FYI @arielb1 mentioned over IRC discussion that he would prefer a more targeted fix oriented around changes to MIR-trans.

@pnkfelix
Copy link
Member Author

@nikomatsakis @arielb1 :

We should decide whether we are going to land this patch or not.

my opinion is that we should put this PR in. It solves the bulk of the occurrences of this problem (see above comment), and guards against adding the bitcast when it is unneeded by first checking if the types already match.

@arielb1
Copy link
Contributor

arielb1 commented Oct 17, 2016

Sure. My patch turned out to be more complicated than it seems.

@bors r+

@bors
Copy link
Contributor

bors commented Oct 17, 2016

📌 Commit 0562654 has been approved by arielb1

@bors
Copy link
Contributor

bors commented Oct 17, 2016

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Oct 17, 2016

📌 Commit 0562654 has been approved by arielb1

bors added a commit that referenced this pull request Oct 17, 2016
Fix ICE: inject bitcast if types mismatch for invokes/calls/stores

Fix ICE: inject bitcast if types mismatch for invokes/calls

Fix #36744
@bors
Copy link
Contributor

bors commented Oct 17, 2016

⌛ Testing commit 0562654 with merge ce31626...

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me modulo nit


fn check_call(typ: &str, llfn: ValueRef, args: &[ValueRef]) {
if cfg!(debug_assertions) {
fn check_call<'b>(&self,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a comment here would be nice-- what is this Cow that is being returned?

@nikomatsakis
Copy link
Contributor

(Oh, I see @arielb1 already r+'d. Seems fine.)

@bors bors merged commit 0562654 into rust-lang:master Oct 17, 2016
@brson brson added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 18, 2016
@brson brson mentioned this pull request Oct 18, 2016
@nikomatsakis nikomatsakis added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Oct 18, 2016
@nikomatsakis
Copy link
Contributor

Accepting for beta. Low risk patch, regression.

cc @rust-lang/compiler

@brson brson removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants