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

LLVM assertion failure with moving boxed DST #35546

Closed
apasel422 opened this issue Aug 9, 2016 · 4 comments · Fixed by #36459
Closed

LLVM assertion failure with moving boxed DST #35546

apasel422 opened this issue Aug 9, 2016 · 4 comments · Fixed by #36459
Assignees
Labels
A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@apasel422
Copy link
Contributor

The following successfully typechecks on rustc 1.12.0-nightly (b30eff7ba 2016-08-05), but generates an LLVM assertion failure:

struct Node<T: ?Sized + Send> {
    next: Option<Box<Node<Send>>>,
    value: T,
}

fn clear(head: &mut Option<Box<Node<Send>>>) {
    while let Some(node) = head.take() {
        *head = node.next;
    }
}

fn main() {}

Error:

rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed.

Note that replacing *head = node.next with *head = node.next.take() (and making node mutable) allows compilation to succeed.

@apasel422 apasel422 added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Aug 9, 2016
@TimNN
Copy link
Contributor

TimNN commented Sep 6, 2016

First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.

@brson brson added I-nominated regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-typesystem Area: The type system labels Sep 7, 2016
@TimNN
Copy link
Contributor

TimNN commented Sep 10, 2016

Using -Z orbit this was introduced between nightly-2016-06-05 and nightly-2016-06-06 (Changes).

@alexcrichton alexcrichton added regression-from-stable-to-beta Performance or correctness regression from stable to beta. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Sep 13, 2016
@nikomatsakis nikomatsakis self-assigned this Sep 13, 2016
@nikomatsakis
Copy link
Contributor

Problem seems to be that we call the drop with a fat pointer as 2 arguments, but it expects a pointer to a tuple.

@nikomatsakis
Copy link
Contributor

I have a fix for this, running the full make check locally now to see if I broke anything else on the way.

Manishearth added a commit to Manishearth/rust that referenced this issue Sep 15, 2016
invoke drop glue with a ptr to (data, meta)

This is done by creating a little space on the stack. Hokey, but it's the simplest fix I can see, and I am in "kill regressions" mode right now.

Fixes rust-lang#35546

r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants