Change:
Hello I admit it is a bit hard to say where exactly the problem lies, but I think something in rustc might be to blame here. I first reported it to alacritty directly, but the more info I gather I think it might be here: In short, on one of my computers, alacritty crashes with this panic on start: Further information: Works fine with stable. The last working nightly is nightly-2018-02-10, as provided by rustup. It is broken only on one of my computers and only when I compile it with . If I had to guess, I'd say it has something to do with switch to llvm 6. Current nightly version info (still broken): I believe my is also relevant (it's some low-power celeron). Is there any other way I could narrow it down further, or anything more I could try?
For the record, if you run it will tell you exactly as what your cpu is recognized (2nd line) :)
Hmm. It says amdfam10, which seems wrong, considering this CPU is intel (and I could see why that would produce strange crashes). How does it detect the CPU? Does it rely on some library present in the OS, or is everything bundled within the tarball downloaded by rustc? (I ask because I have an unusual setup ‒ this is gentoo and the packages for the computer are compiled on a different computer, so some library in the OS could in theory provide the info from the time it was compiled, not where it runs, but it sounds unlikely).
Just to add, the 2018-02-10 version guesses silvermont.
Just curious, if you run, do you see something like "illegal instruction" or "invalid opcode" at the bottom when you execute the probably miscompiled binary?
Host CPU detection is done by LLVM .
are you sure you looked at the and not amdfam10 is definitely not something that should be detected for intel.
Yes, I'm sure (and just double-checked). The fact the amdfam10 is first in the list is suspicious, though (something initialized to 0 and not set later on, maybe). I fully agree this should not be detected on intel. (As for the dmesg and illegal instruction, I'll report back in ~30 minutes ‒ I have to get back to the broken state and the processor is slow).
No illegal instruction dmesg, only well-behaved panic. But I think it is possible there exists an instruction opcode that means one thing on the amdfam10 processor and something completely different on the intel one.
I'd have expected a if a truly illegal/unsupported instruction was attempted, rather than an assertion panic inside Rust code. The tricky bit here is that amdfam10 supports the x86-64 ISA, and even some SSE extensions; as does silvermont, of course. Perhaps the panic can be turned into an abort, get a core dump, and then look at the disassembly of the frames in the backtrace. In particular, what is the HashMap trying to resize to? That seems to cause an overflow in multiplication, and perhaps it's getting some bogus value. Then maybe it's possible to trace back to see where this value is produced, and perhaps there's some sort of miscompile there. Or, can skip that and try to figure out why cpu detection is off in the first place. you said that this nightly version works fine if you manually select silvermont?
It works fine if I pass no RUSTFLAGS (eg. compile generic code). I'm compiling with explicit silvermont now, but I'd expect that to work too.
does it always fail with ? And always in the same place?
If I explicitly select silvermont, it also works correctly. With native, it always fails and the function names and line numbers in the backtrace are the same. The addresses on the left differ, probably due to some kind of address space randomization.
I believe it is the choice of wrong processor during the compilation. But I still went with the experiment and created a core file. The capacity is something ridiculously large. I'm attaching the core file and corresponding binary, if you want to look into it.

Discussion:
let code_model = to_llvm_code_model(sess.code_model()); <del> let features = attributes::llvm_target_features(sess).collect::<Vec<_>>(); </del> <ins> let mut features = llvm_util::handle_native_features(sess); features.extend(attributes::llvm_target_features(sess).map(|s| s.to_owned())); </ins> let mut singlethread = sess.target.singlethread; // On the wasm target once the `atomics` feature is enabled that means that

PM: &PassManager<'_>, ); <ins> pub fn LLVMGetHostCPUFeatures() -> *mut c_char; pub fn LLVMDisposeMessage(message: *mut c_char); </ins> // Stuff that's in llvm-wrapper/ because it's not upstream yet. /// Opens an object file.

use rustc_session::Session; use rustc_span::symbol::Symbol; use rustc_target::spec::{MergeFunctions, PanicStrategy}; <del> use std::ffi::CString; </del> <ins> use std::ffi::{CStr, CString}; </ins> use std::slice; use std::str;

handle_native(name) } <ins> pub fn handle_native_features(sess: &Session) -> Vec<String> { match sess.opts.cg.target_cpu { Some(ref s) => { if s != "native" { return vec![]; } let features_string = unsafe { let ptr = llvm::LLVMGetHostCPUFeatures(); let features_string = if !ptr.is_null() { CStr::from_ptr(ptr) .to_str() .unwrap_or_else(|e| { bug!("LLVM returned a non-utf8 features string: {}", e); }) .to_owned() } else { bug!("could not allocate host CPU features, LLVM returned a `null` string"); }; llvm::LLVMDisposeMessage(ptr); features_string }; features_string.split(",").map(|s| s.to_owned()).collect() } None => vec![], } } </ins> pub fn tune_cpu(sess: &Session) -> Option<&str> { match sess.opts.debugging_opts.tune_cpu { Some(ref s) => Some(handle_native(&**s)),