SIGSEGV when tested with gcc-12 on macos

[devcrocod]

os: macOS 12.5.1
arch: x86_64
C compiler: gcc-12 (Homebrew GCC 12.1.0) 12.1.0
Fortran compiler: GNU Fortran (Homebrew GCC 12.1.0) 12.1.0
OpenBLAS version: 0.3.20/0.3.21/develop

make command:

make CC=gcc-12 FC=gfortran-12 HOSTCC=gcc BINARY=64 F_COMPILER=GFORTRAN FEXTRALIB=-lgfortran USE_OPENMP=0 NO_AVX512=1 DYNAMIC_ARCH=1 NUM_THREADS=64

When testing Complex BLAS, I get segmentation fault:

 Complex BLAS Test Program Results


 Test of subprogram number  1            ZDOTC 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10ef5b90e
#1  0x10ef5aaed
#2  0x7ff80b637dfc
#3  0x10e7980c0
#4  0x10e798361
#5  0x10be5ee06
#6  0x10be5f0d4
#7  0x10e924e8e
make[5]: *** [level1] Segmentation fault: 11
make[5]: *** Waiting for unfinished jobs....

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x1060d990e
#1  0x1060d8aed
#2  0x7ff80b637dfc
#3  0x1059025a0
#4  0x105902841
#5  0x102f9ac86
#6  0x102f991f6
#7  0x102f92cd1
#8  0x102f979b3
#9  0x105a8f13e
/bin/sh: line 1: 72622 Segmentation fault: 11  OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./zblat2 < ./zblat2.dat

[martin-frbg]

hmm, this used to work with earlier gcc, so should not be anything fundamental (like internal representation of complex numbers).I wonder if this could be a regression in gcc-12 itself. (Have not updated gcc in our CI yet and am currently travelling)

[martin-frbg]

fails at -O2, passes at just -g (so -O0), looks like overenthusiastic optimization by version 12.1 to me

[devcrocod]

Unfortunately, I can no longer use gcc-11. I also tried running on gcc version 12.2.0 and got the same error

[martin-frbg]

make ... COMMON_OPT=-O1 also works with gcc-12, it only goes wrong at O2

[martin-frbg]

make COMMON_OPT="-O2 -fno-tree-vectorize is probably the best solution for now.(Default activation of the autovectorizer at O2 instead of O3 was one of the major changes in gcc-12)

[martin-frbg]

This "gcc-12" problem is not seen on x86_64 running Linux, nor on an Apple M1 running Linux, so may be peculiar to OSX builds

[mmuetzel]

It looks like this also happens with the gcc-12 in MSYS2 on Windows: msys2/MINGW-packages#12857
Checking currently if re-building with -O2 -fno-tree-vectorize helps.

Edit: Building with -O2 -fno-tree-vectorize seems to fix the segfault on Windows, too.

[mmuetzel]

Is there a recommended optimization level for building OpenBLAS?

[martin-frbg]

Traditionally just -O2 (see Makefile.rule) but cmake defaults to -O3 for Release builds. I had already deactivated the tree vectorizer for building the tests with gcc-11/cmake earlier, maybe more changed in gcc-12's vectorizer than just default activation but it will take time to identify the miscompiled code.

[mmuetzel]

Is it these lines?
https://github.com/xianyi/OpenBLAS/blob/00534523ad999d89945d23b7df0eafc69c31f1b3/Makefile.system#L1552
https://github.com/xianyi/OpenBLAS/blob/00534523ad999d89945d23b7df0eafc69c31f1b3/Makefile.system#L1556

Only tangentially related to this issue: Would it make sense for the cmake build rules to set CMAKE_C_FLAGS_RELEASE="-O2" (and similarly for Fortran and Assembler)? IIUC, that would make the resulting binaries more similar when using cmake or make.
Edit: And it would probably come with the benefit of avoiding the issue here with default settings.