SBCL 2.2.7: SIGILL on AVX-enabled 256 SIMD packing

Bug #1983612 reported by Patrick Poitras
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
New
Undecided
Unassigned

Bug Description

AVX systems are still crashing on trying to pack 256-bit registers. There's a related bug where there was a patch for this issue released in SBCL 2.2.7, but it still seems to be an issue in 2.2.7. Computers that this runs on are AVX enabled, but lack AVX2, Docker containers running on a cluster. I am willing to help out fixing this if there's ways I can help.

Reproducible test case.

(asdf:load-system :sb-simd)
(use-package :sb-simd-avx)
(f64.4 0d0)

OUTPUT FROM sbcl --version
SBCL 2.2.7

OUTPUT FROM uname -a
Linux <session-name> 4.15.0-184-generic #194-Ubuntu SMP Thu Jun 2 18:54:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

CPU 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 smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d

OUTPUT FROM *features*

;; From SLIME
(:SWANK :CLPM-CLIENT :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
 :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE
 :SBCL :UNIX)

;; From SBCL in terminal.
(:CLPM-CLIENT :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
 :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE
 :SBCL :UNIX)

SBCL CRASH OUTPUT
 tid 348 CPU state (SIGILL received): PC=534c5273 Flags={IF ZF PF}
              rax rcx rdx rbx rsp rbp rsi rdi
                0 8 0 0 7FA08D495EA0 7FA08D495EB0 0 0
               r8 r9 r10 r11 r12 r13 r14 r15
                0 7FA08D495EB0 50100117 502BA57F 7FA09019B010 7FA08D698080 534C510B A
                              xmm0 xmm1 xmm2 xmm3
  00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 0000003C000000200000006400000020
                              xmm4 xmm5 xmm6 xmm7
  00000063000000200000006200000020 00000061000000200000003400000036 00000062000000750000002D00000036 00000035000000320000002D0000006B
                              xmm8 xmm9 xmm10 xmm11
  000000290000003E0000007D00000042 0000FFFFFFFFFFFFFFFFFFFF0000FFFF 00000000000000000000000000000000 00000000000000000000000000000000
                             xmm12 xmm13 xmm14 xmm15
  00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000
sigmask=
fatal error encountered in SBCL pid 327 tid 348:
Unhandled SIGILL at 0x534c5273.

The system is too badly corrupted or confused to continue at the Lisp.
level. The monitor was enabled, but you requested `sleep_when_lost'
behaviour though dyndebug. To help with your debugging effort, this
thread will not enter the monitor, and instead proceed immediately to an
infinite sleep call, maximizing your chances that the thread's current
state can be preserved until you attach an external debugger. Good luck!

Revision history for this message
Stas Boukarev (stassats) wrote :

> There's a related bug where there was a patch for this issue released in SBCL 2.2.7, but it still seems to be an issue in 2.2.7.

I don't think there was a bug related to this. Anyway, AVX2 is required.

Revision history for this message
Patrick Poitras (pfpoitras) wrote :
Revision history for this message
Stas Boukarev (stassats) wrote :

That was about loading constants in simd-pack-256 at compile-time, not really related to what sb-simd does at compile-time.

Revision history for this message
Patrick Poitras (pfpoitras) wrote :

For what it's worth (sb-ext:%make-simd-pack-256-double 0d0 0d0 0d0 0d0) also crashes with sigill.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers