SIGILL in the binary compiled with `-C target-cpu=native` on the latest nightly

[netvl]

I'm trying to build ripgrep with its SIMD optimizations on, and on Archlinux this means that ripgrep is compiled as follows:

% RUSTFLAGS="-C target-cpu=native" cargo build --release --features simd-accel

However, the build fails with the following error:

% RUSTFLAGS="-C target-cpu=native" cargo build --release --features simd-accel
   Compiling winapi-build v0.1.1
   Compiling fnv v1.0.5
   Compiling crossbeam v0.2.10
   Compiling ansi_term v0.9.0
   Compiling utf8-ranges v0.1.3
   Compiling winapi v0.2.8
   Compiling vec_map v0.6.0
   Compiling log v0.3.6
   Compiling void v1.0.2
   Compiling libc v0.2.18
   Compiling unreachable v0.1.1
   Compiling bitflags v0.7.0
   Compiling unicode-segmentation v0.1.3
   Compiling strsim v0.5.2
   Compiling unicode-width v0.1.3
   Compiling walkdir v1.0.3
   Compiling term_size v0.2.1
   Compiling thread-id v3.0.0
   Compiling regex-syntax v0.3.9
   Compiling thread_local v0.3.0
   Compiling termcolor v0.1.1 (file:///tmp/yaourt-tmp-netvl/aur-ripgrep-git/src/ripgrep-git/termcolor)
   Compiling clap v2.18.0
   Compiling memmap v0.5.0
   Compiling simd v0.1.1
   Compiling kernel32-sys v0.2.2
Build failed, waiting for other jobs to finish...
error: failed to run custom build command for `kernel32-sys v0.2.2`
process didn't exit successfully: `/tmp/yaourt-tmp-netvl/aur-ripgrep-git/src/ripgrep-git/target/release/build/kernel32-sys-f1c920c4b0efc1c4/build-script-build` (signal: 4, SIGILL: illegal instruction)

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:

% git clone https://github.com/retep998/winapi-rs
% cd winapi-rs
% git checkout 00ba888
% cd lib/kernel32
% RUSTFLAGS="-C target-cpu=native" cargo build --release
   Compiling winapi v0.2.8 (file:///tmp/winapi-rs)
   Compiling winapi-build v0.1.1 (file:///tmp/winapi-rs/build)
   Compiling kernel32-sys v0.2.2 (file:///tmp/winapi-rs/lib/kernel32)
error: failed to run custom build command for `kernel32-sys v0.2.2 (file:///tmp/winapi-rs/lib/kernel32)`
process didn't exit successfully: `/tmp/winapi-rs/lib/kernel32/target/release/build/kernel32-sys-70200ca6b7279963/build-script-build` (signal: 4, SIGILL: illegal instruction)

If I omit the RUSTFLAGS variable, everything compiles fine:

% cargo build --release                   
   Compiling winapi v0.2.8 (file:///tmp/winapi-rs)
   Compiling winapi-build v0.1.1 (file:///tmp/winapi-rs/build)
   Compiling kernel32-sys v0.2.2 (file:///tmp/winapi-rs/lib/kernel32)
    Finished release [optimized] target(s) in 0.91 secs

Compiler version:

% rustc -V
rustc 1.15.0-nightly (daf8c1dfc 2016-12-05)
% cargo -V
cargo 0.16.0-nightly (built 2016-12-06)

Also, I'm running a Skylake i7 CPU, here is my /proc/cpuinfo, if it is relevant:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
stepping	: 3
microcode	: 0x9e
cpu MHz		: 3288.598
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 5615.87
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
stepping	: 3
microcode	: 0x9e
cpu MHz		: 3320.043
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 5621.56
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
stepping	: 3
microcode	: 0x9e
cpu MHz		: 3282.275
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 5623.92
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
stepping	: 3
microcode	: 0x9e
cpu MHz		: 3326.367
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 5622.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

[nagisa]

I cannot reproduce.

Does (when run from lib/kernel32) still reproduce?

rustc --crate-name kernel32 src/lib.rs --crate-type lib -C opt-level=3 -C metadata=2fc09ff90264f963 -C extra-filename=-2fc09ff90264f963 --out-dir ./target/release/deps --emit=dep-info,link -L dependency=./target/release/deps --extern winapi=./target/release/deps/libwinapi-ab96afe94df678e7.rlib -C target-cpu=native

If so, could you run it under a debugger and retrieve a backtrace?

gdb --args rustc --crate-name kernel32 src/lib.rs --crate-type lib -C opt-level=3 -C metadata=2fc09ff90264f963 -C extra-filename=-2fc09ff90264f963 --out-dir ./target/release/deps --emit=dep-info,link -L dependency=./target/release/deps --extern winapi=./target/release/deps/libwinapi-ab96afe94df678e7.rlib -C target-cpu=native

(gdb) run
# once the SIGILL happens
(gdb) bt

[netvl]

@nagisa, well, the command you provided does work correctly, but as far as I can see, it happens not in the rustc 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.

[netvl]

Here is the output of cargo build --verbose:

% RUSTFLAGS="-C target-cpu=native" cargo build --verbose --release
   Compiling winapi v0.2.8 (file:///tmp/winapi-rs)
   Compiling winapi-build v0.1.1 (file:///tmp/winapi-rs/build)
     Running `rustc --crate-name winapi /tmp/winapi-rs/src/lib.rs --crate-type lib -C opt-level=3 -C metadata=ab96afe94df678e7 -C extra-filename=-ab96afe94df678e7 --out-dir /tmp/winapi-rs/lib/kernel32/target/release/deps --emit=dep-info,link -L dependency=/tmp/winapi-rs/lib/kernel32/target/release/deps -C target-cpu=native`
     Running `rustc --crate-name build /tmp/winapi-rs/build/src/lib.rs --crate-type lib -C opt-level=3 -C metadata=0ccc9c9bd237e078 -C extra-filename=-0ccc9c9bd237e078 --out-dir /tmp/winapi-rs/lib/kernel32/target/release/deps --emit=dep-info,link -L dependency=/tmp/winapi-rs/lib/kernel32/target/release/deps -C target-cpu=native`
   Compiling kernel32-sys v0.2.2 (file:///tmp/winapi-rs/lib/kernel32)
     Running `rustc --crate-name build_script_build build.rs --crate-type bin -C opt-level=3 -C metadata=70200ca6b7279963 -C extra-filename=-70200ca6b7279963 --out-dir /tmp/winapi-rs/lib/kernel32/target/release/build/kernel32-sys-70200ca6b7279963 --emit=dep-info,link -L dependency=/tmp/winapi-rs/lib/kernel32/target/release/deps --extern build=/tmp/winapi-rs/lib/kernel32/target/release/deps/libbuild-0ccc9c9bd237e078.rlib -C target-cpu=native`
     Running `/tmp/winapi-rs/lib/kernel32/target/release/build/kernel32-sys-70200ca6b7279963/build-script-build`
error: failed to run custom build command for `kernel32-sys v0.2.2 (file:///tmp/winapi-rs/lib/kernel32)`
process didn't exit successfully: `/tmp/winapi-rs/lib/kernel32/target/release/build/kernel32-sys-70200ca6b7279963/build-script-build` (signal: 4, SIGILL: illegal instruction)

[netvl]

In case it is helpful, here is the backtrace for the build script:

Starting program: /tmp/winapi-rs/lib/kernel32/target/release/build/kernel32-sys-70200ca6b7279963/build-script-build 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000555555559946 in core::result::unwrap_failed::h98e39d97d47cde50 ()
(gdb) bt
#0  0x0000555555559946 in core::result::unwrap_failed::h98e39d97d47cde50 ()
#1  0x000055555555a0c8 in build::link::h504eeff8ebb5a460 ()
#2  0x000055555556d47b in panic_unwind::__rust_maybe_catch_panic () at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libpanic_unwind/lib.rs:97
#3  0x000055555556366b in std::panicking::try<(),fn()> () at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:332
#4  std::panic::catch_unwind<fn(),()> () at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:351
#5  std::rt::lang_start () at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/rt.rs:57
#6  0x00007ffff7424291 in __libc_start_main () from /usr/lib/libc.so.6
#7  0x00005555555597da in _start ()

[nagisa]

Could you also x/10i $pc while on the breakpoint in the build script? Thanks.

(Sidenote: seems like #36448 has resurfaced)

[netvl]

Sure. here it is:

(gdb) x/10i $pc
=> 0x555555559946 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+38>:	vmovdqu8 (%rdi),%xmm0
   0x55555555994c <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+44>:	vmovdqu8 %xmm0,(%rsp)
   0x555555559953 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+51>:	
    lea    0x255026(%rip),%rax        # 0x5555557ae980 <_ZN4core6result13unwrap_failed15__STATIC_FMTSTR17h9faf142ae795601eE>
   0x55555555995a <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+58>:	vmovdqu64 (%rax),%xmm0
   0x555555559960 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+64>:	lea    0x20(%rsp),%rax
   0x555555559965 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+69>:	mov    %rax,0x30(%rsp)
   0x55555555996a <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+74>:	
    lea    0x7f(%rip),%rax        # 0x5555555599f0 <_ZN55_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$3fmt17h178215f4e32f16d5E>
   0x555555559971 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+81>:	mov    %rax,0x38(%rsp)
   0x555555559976 <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+86>:	lea    (%rsp),%rax
   0x55555555997a <_ZN4core6result13unwrap_failed17h98e39d97d47cde50E+90>:	mov    %rax,0x40(%rsp)

[netvl]

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.

[nagisa]

vmovdqu8 is indeed an AVX-512 instruction which isn’t supported by your CPU.

As a workaround I suggest using -C target-cpu=skylake and if that doesn’t work -C target-cpu=haswell. Alternatively you could try -C target-feature=-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl along with -C target-cpu=native.

[netvl]

-C target-cpu=skylake did help, thank you!

[mstewartgallus]

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 https://sstewartgallus.com/git?p=uevents-rs.git;a=blob;f=src/cacheline.rs;h=389ab14a9c331f22ecfe35ed91986b2071a6264a;hb=HEAD

[EFanZh]

See here for previous discussion.

I have the same problem.

Compiling the following code on my PC with rustc -C target-cpu=native generates executable that exits with SIGILL signal:

use std::time::SystemTime;

fn main() {
    let n = SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs() % 1000;
    let mut x = 0;

    for i in 0..n {
        x += i;
    }

    println!("{}", x);
}

My compiler and CPU information:

$ rustc --version
rustc 1.30.0-nightly (cb6d2dfa8 2018-09-16)

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):           1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               60
Model name:          Intel(R) Pentium(R) CPU G3250 @ 3.20GHz
Stepping:            3
CPU MHz:             3167.096
CPU max MHz:         3200.0000
CPU min MHz:         800.0000
BogoMIPS:            6385.35
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            3072K
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer xsave rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust erms invpcid xsaveopt dtherm arat pln pts flush_l1d

[GabrielMajeri]

@EFanZh 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 -C target-feature=+avx,+avx2 and confirm that it crashes?