Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

llvm::StructType::getElementType: Assertion `N < NumContainedTys && "Element number out of range!"' failed. #21721

Closed
eddyb opened this issue Jan 28, 2015 · 6 comments · Fixed by #22526 or #22837
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@eddyb
Copy link
Member

eddyb commented Jan 28, 2015

pub fn maybe_ptr() -> *const u8 {
    static NONE: Option<((), &'static u8)> = None;
    unsafe {
        *(&NONE as *const _ as *const *const u8)
    }
}

Running this in the playpen gives:

rustc: /build/rust-git/src/rust/src/llvm/include/llvm/IR/DerivedTypes.h:285: llvm::Type* llvm::StructType::getElementType(unsigned int) const: Assertion `N < NumContainedTys && "Element number out of range!"' failed.
Aborted (core dumped)

This is actually happening inside LLVM optimizations, in the early-cse pass (-C opt-level=1 still triggers it). Originally found in a memcpy optimized into a load.
Reduced LLVM IR:

target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@NONE = internal constant { { {}, i8* } } zeroinitializer

define i8* @maybe_ptr() {
entry-block:
  %0 = load i8** bitcast ({ { {}, i8* } }* @NONE to i8**)
  ret i8* %0
}

cc @dotdash

@eddyb eddyb added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 28, 2015
@eddyb
Copy link
Member Author

eddyb commented Jan 28, 2015

Current LLVM fork tip: rust-lang/llvm@b820135 on top of llvm-mirror/llvm@0ad623b.

@dotdash
Copy link
Contributor

dotdash commented Feb 15, 2015

eddyb added a commit to eddyb/rust that referenced this issue Feb 16, 2015
dotdash added a commit to dotdash/rust that referenced this issue Feb 19, 2015
Manishearth added a commit to Manishearth/rust that referenced this issue Feb 20, 2015
dotdash added a commit to dotdash/rust that referenced this issue Feb 21, 2015
bors added a commit that referenced this issue Feb 21, 2015
bors added a commit that referenced this issue Feb 22, 2015
bors added a commit that referenced this issue Feb 23, 2015
@eddyb
Copy link
Member Author

eddyb commented Feb 24, 2015

This needs a test, and there's also two hacks introduced by #21744, that should be reverted now that the LLVM bug is fixed (they both reference this issue).

@eddyb eddyb added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Feb 24, 2015
@eddyb eddyb reopened this Feb 24, 2015
@dotdash
Copy link
Contributor

dotdash commented Feb 24, 2015

@eddyb will you take care of that?

@pczarn
Copy link
Contributor

pczarn commented Feb 26, 2015

I'm still getting this failure in #21973 during the compilation of rustc-trans

@dotdash
Copy link
Contributor

dotdash commented Feb 27, 2015

I guess you get that in stage0? That will need a new snapshot, so that the
stage0 compiler also uses the new LLVM
Am 26.02.2015 20:40 schrieb "Piotr Czarnecki" notifications@github.com:

I'm still getting this failure in #21973
#21973


Reply to this email directly or view it on GitHub
#21721 (comment).

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
3 participants