Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2

On 29 Dec 2023, at 11:14, Harry Schmalzbauer <freebsd@omnilan.de> wrote:
> 
> at least since 14-release, I can't compile base/ports with CPUTYPE post nehalem.  Any '-march' declaring AVX(*) capability leads to SIGILLing binaries with default -O2 CFLAGS.
> Not much of a help, but here's a ports example, but same result with base outcome too:
> 
> zsh: illegal hardware instruction (core dumped) /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim
> kernel: pid 56502 (vim), jid 0, uid 0: exited on signal 4 (core dumped)
> 
> gdb /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/runtime/doc/vim.core
> 
> GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD]
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd14.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim...
> [New LWP 154051]
> Core was generated by `/var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim --clean -esX -V'.
> Program terminated with signal SIGILL, Illegal instruction.
> Privileged opcode.
> #0  0x000000000041e040 in init_yank ()
> 
> 
> If I compile without CFLAGS -O2 ("CFLAGS= -pipe"), -march=skylake-avx512 the binary doens't crash with SIGILL.
> 
> Is CPUTYPE supposed to stay untouched these days?

Obviously not, but are you sure your target CPU is correct? If it is not, the compiler may insert unsupported instructions.

In any case, for the above gdb session, try the command "disassemble" to see which particular instruction it crashed on. That may give more information.

-Dimitry