Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
netvl opened this issue Dec 7, 2016 · 13 comments · Fixed by #80749
Closed

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

netvl opened this issue Dec 7, 2016 · 13 comments · Fixed by #80749
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@netvl
Copy link
Contributor

netvl commented Dec 7, 2016

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
Copy link
Member

nagisa commented Dec 7, 2016

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
Copy link
Contributor Author

netvl commented Dec 7, 2016

@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
Copy link
Contributor Author

netvl commented Dec 7, 2016

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
Copy link
Contributor Author

netvl commented Dec 7, 2016

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
Copy link
Member

nagisa commented Dec 7, 2016

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

(Sidenote: seems like #36448 has resurfaced)

@netvl
Copy link
Contributor Author

netvl commented Dec 9, 2016

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
Copy link
Contributor Author

netvl commented Dec 9, 2016

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
Copy link
Member

nagisa commented Dec 9, 2016

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
Copy link
Contributor Author

netvl commented Dec 10, 2016

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

@mstewartgallus
Copy link
Contributor

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

@Mark-Simulacrum Mark-Simulacrum added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 23, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 26, 2017
@EFanZh
Copy link
Contributor

EFanZh commented Sep 25, 2018

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
Copy link
Contributor

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

@EFanZh
Copy link
Contributor

EFanZh commented Sep 30, 2018

@GabrielMajeri 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 detect my CPU’s capability correctly, so I think Rust should do it too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants