cblat1 test segfaults on macOS x64

[Maxwell175]

I am working on building openBLAS for the x64 architecture on macOS using flang-new. Here is the make command in use:

arch -x86_64 make FC=/Users/m1/Library/Nuitka-Python311/build_tools/clang/bin/flang-new "FCOMMON_OPT=-Wl,-syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" NO_SHARED=1 TARGET=NEHALEM "CFLAGS=-arch x86_64" -j8

The issue is that once the build gets to running the tests, the cblat1 test fails with a Segmentation fault. To get a bit more info, I recompiled that test by hand replacing the -O2 flag with -g. Here are the results in lldb:

╰─➤  lldb cblat1 
(lldb) target create "cblat1"
Current executable set to '/Users/m1/OpenBLAS-0.3.29/test/cblat1' (x86_64).
(lldb) r
Process 46323 launched: '/Users/m1/OpenBLAS-0.3.29/test/cblat1' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

 Complex BLAS Test Program Results


 Test of subprogram number  1            CDOTC 
Process 46323 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
    frame #0: 0x000000010000230f cblat1`cdotc_ + 15
cblat1`cdotc_:
->  0x10000230f <+15>: movslq (%r9), %rax
    0x100002312 <+18>: movslq (%rcx), %r9
    0x100002315 <+21>: movl   $0x2, %r10d
    0x10000231b <+27>: subq   %rdi, %r10
Target 0: (cblat1) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
  * frame #0: 0x000000010000230f cblat1`cdotc_ + 15
    frame #1: 0x0000000100001440 cblat1`check2_ at cblat1.f:535:16
    frame #2: 0x0000000100000827 cblat1`_QQmain at cblat1.f:78:13
    frame #3: 0x0000000100001f22 cblat1`main at cblat1.f:724:7
    frame #4: 0x00000002000ea2cd dyld`start + 1805

[martin-frbg]

which version of flang-new is this please ?

[Maxwell175]

It is the latest stable, 19.1.7.

[martin-frbg]

Thanks - this could be a misdetection of flang-new as "classic flang", leading to wrong ABI assumptions. Can you check if your Makefile.conf has F_COMPILER as FLANG or FLANGNEW please ?

[Maxwell175]

That was indeed the issue!

[martin-frbg]

Thanks for confirming... took me a while to understand what was going on. I guess the next issue is going to be how to make building a shared library work with this setup.

[Maxwell175]

@martin-frbg Actually that didn't fix it. I still get a segfault, but on an even earlier test. ./openblas_utest gives `TEST 1/109 min:smin_negative [SIGNAL 11: Segmentation fault: 11]

Before the latest commit, it was indeed misidentified as FLANG instead of FLANGNEW. Now it is recognized as FLANGNEW.

The test that was failing before works now I think:

─➤  ./cblat1
 Complex BLAS Test Program Results


 Test of subprogram number  1            CDOTC 
                                    ----- PASS -----

 Test of subprogram number  2            CDOTU 
                                    ----- PASS -----

 Test of subprogram number  3            CAXPY 
                                    ----- PASS -----

 Test of subprogram number  4            CCOPY 
                                    ----- PASS -----

 Test of subprogram number  5            CSWAP 
                                    ----- PASS -----

 Test of subprogram number  6            SCNRM2
                                    ----- PASS -----

 Test of subprogram number  7            SCASUM
                                    ----- PASS -----

 Test of subprogram number  8            CSCAL 
                                    ----- PASS -----

 Test of subprogram number  9            CSSCAL
                                    ----- PASS -----

 Test of subprogram number 10            ICAMAX
                                    ----- PASS -----
Fortran STOP
IEEE arithmetic exceptions signaled: INEXACT

[martin-frbg]

Doesn't crash in the new CI job though - main difference seems to be that I do not specify a syslibroot via FCOMMON_OPT (but I do not see how this would affect SMIN (where the test is simply finding the smallest of three negative numbers).
Which C compiler does your make run find - I notice you are only specifying the FC ?

[Maxwell175]

@martin-frbg It seems that it is just calling cc:

─➤  cc -v                                                                                                                                                                   2 ↵
Apple clang version 16.0.0 (clang-1600.0.26.4)
Target: arm64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[martin-frbg]

Do you have only flang-new installed from LLVM19.1.7, or clang as well ? I mean could you try setting CC= to the 19.1.7 version of clang in case there were any interoperability changes

[Maxwell175]

@martin-frbg Mixing a custom clang with the system libraries is quite problematic, so I am only using flang-new from LLVM.

[martin-frbg]

Ah, OK - not that familiar with the Apple ecosystem. I wonder about the possible influence of (not) setting libsysroot though

[Maxwell175]

@martin-frbg Then it doesn't find the system libraries like libSystem, etc.

[martin-frbg]

so my build (in CI) does not have this problem because I used the clang and related libraries from LLVM, but this is actually discouraged for the reasons you mentioned ?