Change:
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

Discussion:
Because LLVM doesn't know what is, we currently , relying on the  function. So if the current CPU's family is Haswell, we convert to . As noticed and , some Intel Pentiums belong to the Haswell microarch, but they lack AVX. <hr/Here are the flags Clang generates for : Not only does it set the right for optimization purposes, it actually manually enables / disables all the features available / not available on the host. This ensures no matter what the microarch is, only available features will be used. <hr/We should probably use the . I think this issue will supersede both rust-lang/rust and rust-lang/rust. If we can fix this, we will never generate code with unavailable target features. Reproducing these errors is pretty hard, unless you have a machine with a Haswell Intel Pentium. I think it might be possible to reproduce this in QEMU with
Alternatively, we could also use the macros to do this. I'll work on this.
To add another example, doesn't detect the feature on broadwell (see ).
I submitted a PR for a

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.

I'm trying to build ripgrep with its SIMD optimizations on, and on Archlinux this means that ripgrep is compiled as follows: However, the build fails with the following error: I tried checking out the appropriate commit in the winapi-rs repo where kernel32-sys 0.2.2 is available, and was able to reproduce this problem directly with the kernel32-sys crate: If I omit the RUSTFLAGS variable, everything compiles fine: Compiler version: Also, I'm running a Skylake i7 CPU, here is my /proc/cpuinfo, if it is relevant:
I cannot reproduce. Does (when run from lib/kernel32) still reproduce? If so, could you run it under a debugger and retrieve a backtrace?
well, the command you provided does work correctly, but as far as I can see, it happens not in the itself but in the build script, and not when compiling that script but when it is run. So, it seems that rustc generates invalid assembly for the build script.
Here is the output of :
In case it is helpful, here is the backtrace for the build script:
Could you also while on the breakpoint in the build script? Thanks. (Sidenote: seems like has resurfaced)
Sure. here it is:
BTW, I had encountered it when I tried to install ripgrep somewhere around a month or a month and a half ago, there was exactly the same problem but I didn't report it then because I thought it was one of those occasional nightly instabilities.
is indeed an AVX-512 instruction which isn’t supported by your CPU. As a workaround I suggest using and if that doesn’t work . Alternatively you could try along with .
did help, thank you!
I have a similar problem where Rust is generating vmov instructions and these workarounds don't seem to work. I am using an Intel(R) Celeron(R) 2955U @ 1.40GHz. I think this is due to me using a repr(simd) hack to obtain better alignment (see ;a=blob;;h=;hb=HEAD
See for previous discussion. I have the same problem.

Compiling the following code on my PC with generates executable that exits with SIGILL signal: My compiler and CPU information:
The issue is that Rust will generate code for your CPU family, which is the Haswell family. In theory, AVX is architecturally guaranteed on Haswell, but some CPUs like your Pentium lack it. Could you try compiling with no flags, and then add and confirm that it crashes?
I agree with you. Currently I can’t test your command, but I think it will crash If I enable AVX. Both gcc and clang can , so I think Rust should do it too.