Change:
let _ = fs::remove_dir_all(&dst.join("build")); t!(fs::create_dir_all(&dst.join("build"))); <del> let assertions = if build.config.llvm_assertions {"ON"} else {"OFF"}; </del> <ins> let mut assertions = if build.config.llvm_assertions {"ON"} else {"OFF"}; // Disable LLVM assertions on ARM compilers until #32360 is fixed if target.contains("arm") && target.contains("gnu") { assertions = "OFF"; } </ins> // http://llvm.org/docs/CMake.html let mut cfg = cmake::Config::new(build.src.join("src/llvm"));

Discussion:
Backtrace Removing any line that's not just whitespace from makes the LLVM assertion disappear. Compiler produced with: A compiler built without optimizations (see arguments below) never hits the LLVM assertion. A compiler built with optimizations and without debug information (see arguments 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 rust-lang/rust. cc
Do you mean like
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.
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. What arguments did you pass to to hit the llvm assertion? ? Also, are you bootstraping the rust compiler on an ARM device or cross compiling rustc on a x86_64 host?
It was a native build using the following flags and no additional : In other words it was a llvm build.
Was the host or ?
It's minus neon during bootstrap. We're talking about the C++ part here and that has to be or it wouldn't compile and link on a native system.
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 .

Enabling debug information () or building LLVM in Debug/Release mode don't affect the presence of the bug. When debug information is enabled and hits an assertion, trying to get more information with 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 foreign function call in the branch of 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 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. Thoughts?
I've had a few 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 rustc. (built with gcc ) BTW, llvm assertions didn't allow me to proceed beyond so reenabling them might be a bit premature. EDIT: I can see you 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 () for me. Can you give them a try? You need the rustc and std components/tarballs from . Those were built with a gcc-4.9.3 using the configure command at the top of . 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 . The original C function uses an enum that should be 32 bits wide, we're passing a aka though. This means that the C function expects a 32bit value in , but the 64bit value is passed in and .

Could one of you test this for me?
Indeed, rustc bootstrapped natively has been completely free of those latter issues. I might try it some time later, but outside of the assertions bug that we've both experienced, it seems like it could be another ARM cross-compilation . I seem to have missed the moment rustc (and not just std) became available for ARM - probably still undergoing tests ;)
started a build with your patch on top of . Will get back to you when I get some results. There's also but it seems to be having some issues as well (can't fetch crates). I want to announce them both when Just Works.
hm I think you're right! We'll probably need to define our own copies of this function, however. The C API , however that are larger than 32-bits. Basically we probably just need and and call those instead.
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 , so the quick'n'dirty patch should be sufficient for a test.
patch gets rid of the LLVM assertions related to AttributeSet () as far as I've tested: clap, cargo, hyper. 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. IIRC You mentioned you hit an ICE while compiling git2 for *BSD. Was that the same one as the assertion above?
Thanks! I'll go and prepare a proper PR. The other assert looks like the error than got as well, I fixed that the other day but the fix is not in the version you tested with.
Oops, forgot to link the other issue, which was