ARM compilers always hit an LLVM assertion (if enabled) during codegen. #32360
Comments
workaround for rust-lang#32360
|
Do you mean like this one? |
|
@petevine Yeah, that's the assertion I'm talking about. I'd be great if you paste a stack trace of that llvm assertion here, otherwise I'll get to it eventually. |
src/llvm/lib/IR/Attributes.cpp:876: llvm::AttributeSet llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const: Assertion `!Attrs.hasAttribute(Index, Attribute::Alignment) && "Attempt to change alignment!"' failed.
(gdb) bt
#0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
#1 0xb6a30f0e in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2 0xb6a33766 in __GI_abort () at abort.c:89
#3 0xb6a2c150 in __assert_fail_base (fmt=0x1 <error: Cannot access memory at address 0x1>,
assertion=0xb41c8e88 "!Attrs.hasAttribute(Index, Attribute::Alignment) && \"Attempt to change alignment!\"", assertion@entry=0x0,
file=0xb41c8434 "/src/llvm/lib/IR/Attributes.cpp", file@entry=0xb244f2a0 "\001", line=876, line@entry=3064918188,
function=function@entry=0xb4c744f0 "llvm::AttributeSet llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const") at assert.c:92
#4 0xb6a2c1e6 in __GI___assert_fail (assertion=0x0, file=0xb244f2a0 "\001", line=3064918188,
function=0xb4c744f0 "llvm::AttributeSet llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const") at assert.c:101
#5 0xb3dc95cc in llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const ()
from /arm-unknown-linux-gnueabihf/stage1/bin/../lib/librustc_llvm-9026086f.so
#6 0xb3e09170 in LLVMRemoveFunctionAttr ()
from /arm-unknown-linux-gnueabihf/stage1/bin/../lib/librustc_llvm-9026086f.so
#7 0xb628e5ec in trans::attributes::from_fn_attrs::h75cc605b937fa118Rlh ()
from /arm-unknown-linux-gnueabihf/stage1/bin/../lib/librustc_trans-9026086f.so
#8 0xb6258b7c in ?? ()
from /arm-unknown-linux-gnueabihf/stage1/bin/../lib/librustc_trans-9026086f.so |
disable llvm assertions on ARM compilers workaround for #32360 r? @alexcrichton
|
Are you saying LLVM is not to blame in any way here? |
|
Updated top comment with a more complete backtrace.
I don't discard that possibility. Last year, when I was looking for the cause of this bug, I was under the impression that the assertion was caused because the rustc backend was driving LLVM in some incorrect way but I'm not sure anymore, as I mentioned in the top comment, a compiler built with: doesn't hit the LLVM assertion. @petevine What arguments did you pass to |
|
It was a native build using the following
In other words it was a |
|
@petevine Was the host |
|
It's |
|
This appears to be a bug in LLVM ARM codegen that has been introduced recently. Disabling LLVM assertions doesn't help, actually it just moves the problem from hitting a LLVM assertion during compilation to a segmentation fault. All our ARM rustc nightlies are affected (they all SIGSEGV). The "fix" I have found is to rollback our LLVM fork to the rust-llvm-2016-02-16 branch. An ARM rustc cross compiled with that LLVM checkout can successfully compile clap and hyper. As for the actual behavior of the bug -- it's a "heisenbug". This is what I've found out:
I would suggest the following steps:
@alexcrichton Thoughts? |
|
@japaric I've had a few BTW, llvm assertions didn't allow me to proceed beyond EDIT: |
You mean using a rustc bootstrapped natively? The rustc nightlies built via cross compilation are segfaulting ( Could the problem by the gcc cross compiler? It could be mis-crosscompiling recent versions of LLVM. |
|
I did a quick check of the code, and it might be that we're just using the wrong type in Could one of you test this for me? diff --git a/src/librustc_llvm/lib.rs b/src/librustc_llvm/lib.rs
index c1b909b..71f760d 100644
--- a/src/librustc_llvm/lib.rs
+++ b/src/librustc_llvm/lib.rs
@@ -965,8 +965,8 @@ extern {
Name: *const c_char,
Value: *const c_char);
pub fn LLVMRemoveFunctionAttrString(Fn: ValueRef, index: c_uint, Name: *const c_char);
- pub fn LLVMGetFunctionAttr(Fn: ValueRef) -> c_ulonglong;
- pub fn LLVMRemoveFunctionAttr(Fn: ValueRef, val: c_ulonglong);
+ pub fn LLVMGetFunctionAttr(Fn: ValueRef) -> c_uint;
+ pub fn LLVMRemoveFunctionAttr(Fn: ValueRef, val: c_uint);
/* Operations on parameters */
pub fn LLVMCountParams(Fn: ValueRef) -> c_uint;
diff --git a/src/librustc_trans/trans/attributes.rs b/src/librustc_trans/trans/attributes.rs
index 4ea920c5..a043d58 100644
--- a/src/librustc_trans/trans/attributes.rs
+++ b/src/librustc_trans/trans/attributes.rs
@@ -29,7 +29,7 @@ pub fn inline(val: ValueRef, inline: InlineAttr) {
llvm::Attribute::AlwaysInline |
llvm::Attribute::NoInline;
unsafe {
- llvm::LLVMRemoveFunctionAttr(val, attr.bits() as c_ulonglong)
+ llvm::LLVMRemoveFunctionAttr(val, attr.bits() as c_uint)
}
},
};
@@ -44,7 +44,7 @@ pub fn emit_uwtable(val: ValueRef, emit: bool) {
unsafe {
llvm::LLVMRemoveFunctionAttr(
val,
- llvm::Attribute::UWTable.bits() as c_ulonglong,
+ llvm::Attribute::UWTable.bits() as c_uint,
);
}
}
@@ -57,7 +57,7 @@ pub fn unwind(val: ValueRef, can_unwind: bool) {
unsafe {
llvm::LLVMRemoveFunctionAttr(
val,
- llvm::Attribute::NoUnwind.bits() as c_ulonglong,
+ llvm::Attribute::NoUnwind.bits() as c_uint,
);
}
} else {
@@ -75,7 +75,7 @@ pub fn set_optimize_for_size(val: ValueRef, optimize: bool) {
unsafe {
llvm::LLVMRemoveFunctionAttr(
val,
- llvm::Attribute::OptimizeForSize.bits() as c_ulonglong,
+ llvm::Attribute::OptimizeForSize.bits() as c_uint,
);
}
}
@@ -88,7 +88,7 @@ pub fn naked(val: ValueRef, is_naked: bool) {
llvm::SetFunctionAttribute(val, llvm::Attribute::Naked);
} else {
unsafe {
- llvm::LLVMRemoveFunctionAttr(val, llvm::Attribute::Naked.bits() as c_ulonglong);
+ llvm::LLVMRemoveFunctionAttr(val, llvm::Attribute::Naked.bits() as c_uint);
}
}
} |
|
@japaric Indeed, rustc bootstrapped natively has been completely free of those latter issues. I seem to have missed the moment rustc (and not just std) became available for ARM - probably still undergoing tests ;) |
|
@dotdash started a build with your patch on top of 151be09. Will get back to you when I get some results. @petevine There's also cargo for ARM but it seems to be having some issues as well (can't fetch crates). I want to announce them both when |
|
@dotdash hm I think you're right! We'll probably need to define our own copies of this function, however. The C API Basically we probably just need |
|
Yeah, I just didn't want to bother writing all that just to see if I'm right at all, and all current calls to those functions should be fine with |
|
@dotdash's patch gets rid of the LLVM assertions related to AttributeSet (*) as far as I've tested: @dotdash could you send a PR? (*) I got a different LLVM assertion while building cargo, specifically while building git2 v0.4.2: But that's a different issue. @alexcrichton IIRC You mentioned you hit an ICE while compiling git2 for *BSD. Was that the same one as the assertion above? |
|
@japaric Thanks! I'll go and prepare a proper PR. The other assert looks like the error than @alexcrichton got as well, I fixed that the other day but the fix is not in the version you tested with. |
STR
Backtrace
Removing any line that's not just whitespace from
src/lib.rsmakes the LLVM assertion disappear.Meta
Compiler produced with:
A compiler built without optimizations (see
configurearguments below) never hits the LLVM assertion.A compiler built with optimizations and without debug information (see
configurearguments below) also hits the LLVM assertion.This is a rather old regression that I tried to bisect long time ago, and if my memory serves me right I tracked it down to #23011.
cc @alexcrichton
The text was updated successfully, but these errors were encountered: