0.3.30: darwin x86_64 failure in `smin_negative`

[Chrismarsh]

On macos x86_64 15.7 sdk26/clang17, there is a failure in the smin_negative test:

TEST 1/125 min:smin_negative make[1]: *** [Makefile:86: run_test] Bus error: 10

$ lldb -- ./openblas_utest
(lldb) run
Process 82549 launched: '/var/folders/fy/f3nz745x07j5nkpmrh_0jlbm0000gq/T/hin601/spack-stage/spack-stage-openblas-0.3.30-ouflo6blmevfyh2bb3gqecxudkst6lrb/spack-src/utest/openblas_utest' (x86_64)
TEST 1/125 min:smin_negative Process 82549 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1019b8300)
    frame #0: 0x000000010003e130 openblas_utest`.L998 + 32
openblas_utest`.L998:
->  0x10003e130 <+32>: addb   %al, (%rax)
    0x10003e132 <+34>: addb   %al, (%rax)
    0x10003e134 <+36>: addb   %al, (%rax)
    0x10003e136 <+38>: addb   %al, (%rax)
Target 0: (openblas_utest) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1019b8300)
  * frame #0: 0x000000010003e130 openblas_utest`.L998 + 32
    frame #1: 0x0000000100002e9a openblas_utest`__ctest_min_smin_negative_run + 74
    frame #2: 0x0000000100002a4c openblas_utest`ctest_main + 1100
    frame #3: 0x00007ff81c802530 dyld`start + 3056
(lldb) disassemble -f
openblas_utest`.L998:
    0x10003e110 <+0>:  minps  %xmm1, %xmm0
    0x10003e113 <+3>:  minps  %xmm3, %xmm2
    0x10003e116 <+6>:  minps  %xmm2, %xmm0
    0x10003e119 <+9>:  movaps %xmm0, %xmm1
    0x10003e11c <+12>: movhlps %xmm0, %xmm0 ; xmm0 = xmm0[1,1] 
    0x10003e11f <+15>: minps  %xmm1, %xmm0
    0x10003e122 <+18>: movaps %xmm0, %xmm1
    0x10003e125 <+21>: shufps $0x1, %xmm0, %xmm0 ; xmm0 = xmm0[1,0,0,0] 
    0x10003e129 <+25>: minss  %xmm1, %xmm0
    0x10003e12d <+29>: nopl   (%rax)
->  0x10003e130 <+32>: addb   %al, (%rax)
    0x10003e132 <+34>: addb   %al, (%rax)
    0x10003e134 <+36>: addb   %al, (%rax)
    0x10003e136 <+38>: addb   %al, (%rax)
    0x10003e138 <+40>: addb   %al, (%rax)
    0x10003e13a <+42>: addb   %al, (%rax)
    0x10003e13c <+44>: addb   %al, (%rax)
    0x10003e13e <+46>: addb   %al, (%rax)

I'm a bit iffy on this, but it has the feeling of an alignment issue?
This failure does not occur on aarch64 macos.

[martin-frbg]

Hmm, strange - I don't think there were any relevant changes lately. What's the cpu please ?

[djmallum]

The CPU is 2.3 GHz 8-Core Intel Core i9, Chris made this issue, but it occurred on my machine (the info in the issue is accurate).

[martin-frbg]

Thanks. Turns out pretty much everything uses the same SSE kernel from original GotoBLAS that indeed uses aligned moves throughout (as would have been advantageous on cpus 15+ years ago)

[Chrismarsh]

Ah excellent!

[Chrismarsh]

n.b., the cmake build didn't trigger this issue. I'm not sure if that is expected?

[Chrismarsh]

@martin-frbg Do you want us to test #5478 or are you pretty confident in the solution?

[martin-frbg]

CMake defaults to using O3 for "Release" builds and (I think) no optimization options if build type isn't specified. The gmake build defaults to using O2 - maybe that's enough for causing the test data to be misaligned in one build but not the other ?
("Historically" GotoBLAS/OpenBLAS appears to have had an unwritten expectation that arguments would always be aligned - which probably was a given for "HPC" work back in the day when unaligned accesses meant slowdowns everywhere in the code. I've been relaxing this for x86_64 by changing mova.. mnemonics to movu.. on a case by case basis whenever this came up in recent years, but I suspect anyone still using some Core2-era cpu would see this as OpenBLAS getting slower)