Repository navigation
0.3.33 test failure in cblat2 on x86-32 #5787
Description
0.3.33 fails to build on Debian i386 architecture (32-bit x86, which despite its name now corresponds to a minimal requirement of Pentium 4).
The error is the following:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
OPENBLAS_NUM_THREADS=2 ./cblat2 < ./cblat2.dat
#0 0xf7c49889 in ???
#1 0xf7c4863d in ???
#2 0xf7f4759f in ???
#3 0x56dff400 in strsm_kernel_RT_BARCELONA
at ../kernel/x86/trsm_kernel_RT_4x4_sse.S:2310
Segmentation fault
The full log can be found at this address: https://buildd.debian.org/status/fetch.php?pkg=openblas&arch=i386&ver=0.3.33%2Bds-1&stamp=1777066182&raw=0
Activity
martin-frbg commentedon Apr 28, 2026
Curious as I don't think there were any recent changes affecting this old architecture. Did Debian update its default compiler recently ?
svillemot commentedon Apr 28, 2026
The major GCC version is the same (15) as the one that was used for 0.3.32 which succeeded. There has however been a minor update (Debian updates its GCC version from the stable branch at a higher frequency than GCC minor releases). So a possibility is that Debian caught a not-yet-released bug on the stable branch of GCC.
Also note that the hardware is not the same as the one used for 0.3.32, maybe this affects the choice of the kernel used at test time.
martin-frbg commentedon Apr 28, 2026
Can't immediately reproduce this (on cfarm26, but it only has gcc 14.2). I note that our MSYS32 CI has been acting up lately too, but I don't think the two are related as that (zblat3 test hanging) appears to have started a few commits past the release.
martin-frbg commentedon Apr 28, 2026
cfarm27 has 15.2 (but no gfortran), no error there either. (Both systems pick NEHALEM in the tests). Will try building a snapshot of gcc trunk later, but it will probably take some time)
svillemot commentedon Apr 28, 2026
Note that the compiler used for this build is Debian’s gcc-15 version 15.2.0-17, corresponding to git 20260423 from the gcc-15 branch (hence not from trunk).
svillemot commentedon Apr 28, 2026
More specifically, it corresponds to git hash 516198b6c0054042da746f3c93f69f557b33e771 of the gcc repository.
martin-frbg commentedon Apr 30, 2026
32bit Barcelona target appears to be broken with gcc16RC2 as well - sblat3 and cblat3 tests segfault in the respective trsm kernel, zblat3 hangs in trsm (this is probably also the test hang that has recently appeared in CI, after the infrastructure switched to a different model of AMD cpu. Haven't had time yet to check if this is actually a recent breakage, or if the Barcelona target has involuntarily regained popularity
svillemot commentedon May 14, 2026
I have applied commit 3b23194 on top of 0.3.33 and still get a build failure for i386 on Debian build daemons (can’t reproduce it locally):
https://buildd.debian.org/status/fetch.php?pkg=openblas&arch=i386&ver=0.3.33%2Bds-2&stamp=1778756907&file=log
martin-frbg commentedon May 14, 2026
#5810 claims fd862d4 (#5767) is the culprit but I don't buy their (or rather, Claude's) reasoning as nothing should be happening in the trsm interface between the two points.
martin-frbg commentedon May 15, 2026
bisect in #5810 is correct - I should not have removed that quick return. fixed in #5813
svillemot commentedon May 15, 2026
Thanks. Does that mean that #5792 should be reverted?
martin-frbg commentedon May 15, 2026
It could be reverted - but all it changed was the mapping for older Ryzen, which are basically identical to the Haswell target anyway. So there should be no practical reason to have them mapped to Barcelona (again)
Fix TRSM on Barcelona target (and possibly others)