ARM compilers always hit an LLVM assertion (if enabled) during codegen.

[japaric]

STR

// minified ansi-term-0.7.2
// src/lib.rs
#![crate_type = "rlib"]

use std::default::Default;

/// A style is a collection of properties that can format a string
/// using ANSI escape codes.
#[derive(PartialEq, Clone, Copy, Debug)]
pub struct Style {
    is_italic: bool,
    is_underline: bool,
    is_blink: bool,
    is_reverse: bool,
    is_hidden: bool
}

impl Style {
    /// Creates a new Style with no differences.
    pub fn new() -> Style {
        Style::default()
    }
}

impl Default for Style {
    fn default() -> Style {
        Style {
            is_italic: false,
            is_underline: false,
            is_blink: false,
            is_reverse: false,
            is_hidden: false
        }
    }
}

$ rustc src/lib.rs
rustc: /buildslave/rust/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.

Backtrace

#0  __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
#1  0xb6801f0e in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb6804766 in __GI_abort () at abort.c:89
#3  0xb67fd150 in __assert_fail_base (fmt=0x1 <error: Cannot access memory at address 0x1>, assertion=0xb461b76c "!Attrs.hasAttribute(Index, Attribute::Alignment) && \"Attempt to change alignment!\"", assertion@entry=0x0, file=0xb461addc "/buildslave/rust/src/llvm/lib/IR/Attributes.cpp",
    file@entry=0xb21ff270 "\001", line=876, line@entry=3062628524,
    function=function@entry=0xb461be10 <llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const::__PRETTY_FUNCTION__> "llvm::AttributeSet llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const") at assert.c:92
#4  0xb67fd1e6 in __GI___assert_fail (assertion=0x0, file=0xb21ff270 "\001", line=3062628524,
    function=0xb461be10 <llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const::__PRETTY_FUNCTION__> "llvm::AttributeSet llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const") at assert.c:101
#5  0xb38b041c in llvm::AttributeSet::removeAttributes(llvm::LLVMContext&, unsigned int, llvm::AttributeSet) const () from /home/japaric/stage2-C/lib/librustc_llvm-9fb2c48c1d571895.so
#6  0xb38dad54 in LLVMRemoveFunctionAttr () from /home/japaric/stage2-C/lib/librustc_llvm-9fb2c48c1d571895.so
#7  0xb5dc1020 in inline (val=<optimized out>, inline={void (union Value_opaque *, enum InlineAttr)} 0xb5dc0fe8 <rustc_trans::trans::attributes::from_fn_attrs+64>) at /buildslave/rust/src/librustc_trans/trans/attributes.rs:32
#8  rustc_trans::trans::attributes::from_fn_attrs (ccx=<optimized out>, attrs=..., llfn=0xadeb4f64) at /buildslave/rust/src/librustc_trans/trans/attributes.rs:88
#9  0xb5e2e650 in rustc_trans::trans::callee::get_fn (ccx=<optimized out>, def_id=..., substs=<optimized out>) at /buildslave/rust/src/librustc_trans/trans/callee.rs:543
#10 0xb5dc3718 in rustc_trans::trans::callee::Callee<'tcx>::def (ccx=0xb21f5090, def_id=..., substs=<optimized out>) at /buildslave/rust/src/librustc_trans/trans/callee.rs:140
#11 0xb5df5f50 in rustc_trans::trans::base::trans_item (ccx=<optimized out>, item=<optimized out>) at /buildslave/rust/src/librustc_trans/trans/base.rs:2302
#12 0xb5e19bf4 in fnfn () at /buildslave/rust/src/librustc_trans/trans/base.rs:2919
#13 with_task<closure,()> (self=0xb21f9e6c, key=..., op=...) at /buildslave/rust/src/librustc/dep_graph/mod.rs:165
#14 rustc_trans::trans::base::TransItemsWithinModVisitor<'a, 'tcx>.Visitor<'v>::visit_item (self=0xb21f5be0, i=0xb189386c) at /buildslave/rust/src/librustc_trans/trans/base.rs:2909
#15 0xb5dfde20 in visit_nested_item (self=0xb21f5be0, item_id=...) at /buildslave/rust/src/librustc_trans/trans/base.rs:2895
#16 walk_mod<rustc_trans::trans::base::TransItemsWithinModVisitor> (visitor=<optimized out>, module=<optimized out>) at /buildslave/rust/src/librustc_front/intravisit.rs:225
#17 rustc_trans::trans::base::trans_crate (tcx=<optimized out>, mir_map=<optimized out>, analysis=<error reading variable: Cannot access memory at address 0x0>) at /buildslave/rust/src/librustc_trans/trans/base.rs:2752
#18 0xb6ea6904 in fnfn () at /buildslave/rust/src/librustc_driver/driver.rs:941
#19 time<rustc_trans::trans::CrateTranslation,closure> (f=..., do_it=<optimized out>, what=...) at /buildslave/rust/src/librustc/util/common.rs:38
#20 rustc_driver::driver::phase_4_translate_to_llvm (tcx=<optimized out>, mir_map=<error reading variable: Cannot access memory at address 0x0>, analysis=...) at /buildslave/rust/src/librustc_driver/driver.rs:939
#21 0xb6ea48f8 in fnfn (tcx=<optimized out>, mir_map=..., analysis=<error reading variable: Cannot access memory at address 0x0>, result=...) at /buildslave/rust/src/librustc_driver/driver.rs:205
#22 0xb6e9e544 in fnfn (tcx=0xb21f9e18) at /buildslave/rust/src/librustc_driver/driver.rs:923
#23 0xb6e98e58 in with<closure,core::result::Result<core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::trans::CrateTranslation), usize>, usize>> (self=<optimized out>, f=...) at /buildslave/rust/src/libstd/thread/local.rs:211
#24 with<closure,core::result::Result<core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::trans::CrateTranslation), usize>, usize>> (self=<optimized out>, f=...) at /buildslave/rust/src/libstd/thread/local.rs:211
#25 enter<closure,core::result::Result<core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::trans::CrateTranslation), usize>, usize>> (tcx=..., f=...) at /buildslave/rust/src/librustc/middle/ty/context.rs:642
#26 rustc_driver::middle::ty::context::TyCtxt<'tcx>::create_and_enter<closure,core::result::Result<core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::trans::CrateTranslation), usize>, usize>> (s=<optimized out>, arenas=<optimized out>,
    def_map=<error reading variable: Cannot access memory at address 0x0>, named_region_map=<error reading variable: Cannot access memory at address 0x0>, map=..., freevars=<error reading variable: Cannot access memory at address 0x0>, region_maps=<error reading variable: Cannot access memory at address 0x0>,
    lang_items=..., stability=<error reading variable: Cannot access memory at address 0x0>, f=...) at /buildslave/rust/src/librustc/middle/ty/context.rs:521
#27 0xb6e94b1c in rustc_driver::driver::phase_3_run_analysis_passes<closure,core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::trans::CrateTranslation), usize>> (sess=<optimized out>, cstore=<optimized out>, hir_map=..., arenas=<optimized out>, name=..., make_glob_map=<optimized out>, f=...)
    at /buildslave/rust/src/librustc_driver/driver.rs:811
#28 0xb6e69e60 in rustc_driver::driver::compile_input (sess=0xb21fd0b8, cstore=<optimized out>, cfg=..., input=<optimized out>, outdir=<optimized out>, output=<optimized out>, addl_plugins=..., control=<optimized out>) at /buildslave/rust/src/librustc_driver/driver.rs:171
#29 0xb6e58360 in rustc_driver::run_compiler (args=..., callbacks=...) at /buildslave/rust/src/librustc_driver/lib.rs:207
#30 0xb6e55b48 in fnfn () at /buildslave/rust/src/librustc_driver/lib.rs:130
#31 fnfn () at /buildslave/rust/src/librustc_driver/lib.rs:1038
#32 rustc_driver::sys_common::unwind::try::try_fn<closure> (opt_closure=<optimized out>) at /buildslave/rust/src/libstd/sys/common/unwind/mod.rs:127
#33 0xb69a92a0 in __rust_try () from /home/japaric/stage2-C/lib/libstd-6183d680ed4f21d9.so
#34 0xb69a9224 in fnfn (s=<optimized out>) at /buildslave/rust/src/libstd/sys/common/unwind/mod.rs:148
#35 with<closure,core::result::Result<(), Box<Any>>> (self=<optimized out>, f=...) at /buildslave/rust/src/libstd/thread/local.rs:211
#36 std::sys_common::unwind::inner_try (f=0xb6e55a1c <rustc_driver::sys_common::unwind::try::try_fn<closure>>, data=0xb21febe8 "") at /buildslave/rust/src/libstd/sys/common/unwind/mod.rs:133
#37 0xb6e56330 in try<closure> (f=...) at /buildslave/rust/src/libstd/sys/common/unwind/mod.rs:123
#38 rustc_driver::boxed::F.FnBox<A>::call_box (self=0xb2211c90, args=<optimized out>) at /buildslave/rust/src/liballoc/boxed.rs:541
#39 0xb69b65ac in call_once (self=..., args=<optimized out>) at /buildslave/rust/src/liballoc/boxed.rs:550
#40 start_thread (main=0xb227a020) at /buildslave/rust/src/libstd/sys/common/thread.rs:23
#41 std::sys::thread::Thread::new::thread_start (main=0xb227a020) at /buildslave/rust/src/libstd/sys/unix/thread.rs:74
#42 0xb28d2fbc in start_thread (arg=0xb21ff270) at pthread_create.c:314
#43 0xb686f97c in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6

Removing any line that's not just whitespace from src/lib.rs makes the LLVM assertion disappear.

Meta

$ rustc -Vv
rustc 1.9.0-nightly (151be0933 2016-03-19)
binary: rustc
commit-hash: 151be09333b53a761c847107bc659769632ae6c6
commit-date: 2016-03-19
host: armv7-unknown-linux-gnueabihf
release: 1.9.0-nightly

Compiler produced with:

$ configure --enable-llvm-static-stdcpp --enable-rustbuild --release-channel=nightly --enable-debug --enable-optimize --host=armv7-unknown-linux-gnueabihf

---

A compiler built without optimizations (see configure arguments below) never hits the LLVM assertion.

$ configure --enable-llvm-static-stdcpp --enable-rustbuild --release-channel=nightly --enable-debug --host=armv7-unknown-linux-gnueabihf

A compiler built with optimizations and without debug information (see configure arguments below) also hits the LLVM assertion.

configure --enable-llvm-static-stdcpp --enable-rustbuild --release-channel=nightly --host=armv7-unknown-linux-gnueabihf

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

[MagaTailor]

Do you mean like this one?

[japaric]

@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.

[MagaTailor]

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

[MagaTailor]

Are you saying LLVM is not to blame in any way here?

[japaric]

Updated top comment with a more complete backtrace.

Are you saying LLVM is not to blame in any way here?

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:

configure --enable-rustbuild --enable-debug --enable-llvm-static-stdcpp --host=armv7-unknown-linux-gnueabihf

doesn't hit the LLVM assertion.

@petevine What arguments did you pass to configure to hit the llvm assertion? --release-channel=nightly? Also, are you bootstraping the rust compiler on an ARM device or cross compiling rustc on a x86_64 host?

[MagaTailor]

It was a native build using the following configure flags and no additional CXXFLAGS:

--enable-optimize --disable-jemalloc --disable-valgrind-rpass --disable-valgrind --enable-llvm-assertions

In other words it was a Release+Asserts llvm build.

[japaric]

@petevine Was the host arm-unknown-linux-gnueabihf or armv7-unknown-linux-gnueabihf?

[MagaTailor]

It's armv7 minus neon during bootstrap. We're talking about the C++ part here and that has to be armv7-a or it wouldn't compile and link on a native system.

[japaric]

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:

• The bug only appears if rustc was compiled with optimizations, as in configure --enable-optimize.
• Enabling debug information (configure --enable-debug) or building LLVM in Debug/Release mode don't affect the presence of the bug.
• When debug information is enabled and rustc foo.rs hits an assertion, trying to get more information with RUST_LOG=rustc_trans rustc foo.rs makes the bug disappear, as in we don't hit an LLVM assertion in that case.
• gdb backtraces of the LLVM assertion always point to the same place: the LLVMRemoveFunctionAttr foreign function call in the None branch of rustc_trans::trans::attributes::inline function.

I would suggest the following steps:

• rollback the LLVM submodule to the aforementioned branch (2016-02-16). It may be possible to use something newer but we'll have to experiment.
• re-enable LLVM assertions when host=ARM because disabling them didn't help.
• Add a regression test against this bug. I could be running cargo build on clap/hyper/cargo using the ARM rustc under QEMU. I know we don't build ARM rustc when testing PRs but we could run this test at least once on the dist-nightly bots.

@alexcrichton Thoughts?

[MagaTailor]

@japaric I've had a few LLVM related segfaults but they were caused by parallel codegen/lto. Are you saying there exist reproducible crashes using just the standard options? That's not my experience from using native rustc. (built with gcc 4.9.3)

BTW, llvm assertions didn't allow me to proceed beyond stage0 so reenabling them might be a bit premature.

EDIT:
I can see you added a code example in your original submission - neither it, nor e.g. hyper exhibit any problems compiling in absence of assertions. I think you've found another issue, possibly related to cross-compilation or gcc version used.

[japaric]

I can see you added a code example in your original submission - neither it, nor e.g. hyper exhibit any problems compiling in absence of assertions. I think you've found another issue, possibly related to cross-compilation or gcc version used.

You mean using a rustc bootstrapped natively?

The rustc nightlies built via cross compilation are segfaulting (rustc hello.rs) for me. Can you give them a try? You need the rustc and std components/tarballs from here. Those were built with a custom gcc-4.9.3 using the configure command at the top of this page.

Could the problem by the gcc cross compiler? It could be mis-crosscompiling recent versions of LLVM.