Skip to content

ICE: assertion failure in LLVM when returning a struct from "extern" function. #21454

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

Closed
vadimcn opened this issue Jan 21, 2015 · 10 comments · Fixed by #22160
Closed

ICE: assertion failure in LLVM when returning a struct from "extern" function. #21454

vadimcn opened this issue Jan 21, 2015 · 10 comments · Fixed by #22160
Labels
A-codegen Area: Code generation I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@vadimcn
Copy link
Contributor

vadimcn commented Jan 21, 2015

Repro:

#[repr(C)]
pub struct Foo(u32);

pub extern fn bar() -> Foo {
    Foo(0)
}

fn main() {}

ICE:

File: C:/rust/src/llvm/lib/IR/Instructions.cpp, Line 1086

Expression: getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"
@Aatch Aatch added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ A-codegen Area: Code generation labels Jan 21, 2015
@skade
Copy link
Contributor

skade commented Jan 22, 2015

#17257 tracks a number of cases that throw the same error.

@vhbit
Copy link
Contributor

vhbit commented Feb 2, 2015

A couple of hints - it looks like it happens when structure size is actually smaller or equal to register of architecture.

I had the similar report for failing on iOS with the following sample:

#![crate_type = "staticlib"]

#[derive(Copy)]
pub struct Pair {
    foo: u32,
    bar: u32,
}

#[no_mangle]
pub extern fn get_pair() -> Pair {
    Pair {
        foo: 42,
        bar: 10,
    }
}

It fails on x86_64 and aarch64 if foo + bar <= 64 bits, i.e. they are u16 or u32.
When switching to armv7 it fails if foo + bar<= 32 bits

@vhbit
Copy link
Contributor

vhbit commented Feb 2, 2015

@dotdash @Aatch after 6 hours bisecting the verdict is - 6ef0840, part of #20755

@dotdash
Copy link
Contributor

dotdash commented Feb 2, 2015

sigh I actually saw that when I was working on #20755 but didn't come up with a test case that would trigger a problem here and then forgot about it. Will look into this.

@vhbit
Copy link
Contributor

vhbit commented Feb 9, 2015

@dotdash will fix hit the upcoming beta?

@dotdash
Copy link
Contributor

dotdash commented Feb 9, 2015

Sorry, fixing a few regressions in LLVM that affected rust had higher priority for me than this issue (because LLVM is very close to its 3.6 release), so I couldn't devote much time to this issue yet.

But given that the beta is still ~3 weeks away, I'm positive that I'll get around to have it fixed by then.

@vhbit
Copy link
Contributor

vhbit commented Feb 9, 2015

Hmm, beta is on week of Feb 16 (i.e. next week), isn't it?

@skade
Copy link
Contributor

skade commented Feb 9, 2015

@vhbit Yes. http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

Although, as someone hitting that bug, I'd be okay if that were flagged as a known bug and would prefer if semantic issues were cared about first.

@vhbit
Copy link
Contributor

vhbit commented Feb 9, 2015

@skade @dotdash I have nothing against fixing regressions, still be extremely happy to see it fixed as I will be stuck on beta1 following 6 weeks till beta2 or rc1.

dotdash added a commit to dotdash/rust that referenced this issue Feb 10, 2015
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.

Fixes rust-lang#21454
bors added a commit that referenced this issue Feb 11, 2015
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.

Fixes #21454
@vhbit
Copy link
Contributor

vhbit commented Feb 11, 2015

@dotdash 🎉 thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants