Repository navigation
SME1 strmm implementation sometimes leaves output unchanged #5763
Description
When called with CblasNonUnit on ARM, cblas_strmm appears to leave its output unchanged. This can be reproduced with the following C code:
#include <cblas.h>
#include <stdio.h>
void print_matrix(float* mat, uint8_t rows, uint8_t cols) {
for (uint8_t row = 0; row < rows; row++) {
for (uint8_t col = 0; col < cols; col++) {
printf("%.0f ", mat[cols * row + col]);
}
printf("\n");
}
}
int main(void) {
float A[] = {
1403, 1215, 883 , 235 ,
434 , 1903, 624 , 10 ,
740 , 305 , 1196, 326 ,
718 , 133 , 878 , 1633,
};
float B[] = {
146 , 1851, 942,
940 , 1327, 503,
852 , 696 , 364,
1568, 1701, 130,
};
print_matrix(A, 4, 4);
printf("\n");
print_matrix(B, 4, 3);
printf("\n");
cblas_strmm(CblasRowMajor, CblasLeft, CblasUpper, CblasTrans, CblasNonUnit, 4, 3, 1.0, A, 4, B, 3);
print_matrix(B, 4, 3);
}(edit: accidentally wrote col < rows before)
With openblas 0.3.30, the program outputs this:
1403 1215 883 235
434 1903 624 10
740 305 1196 326
718 133 878 1633
146 1851 942
940 1327 503
852 696 364
1568 1701 130
204838 2596953 1321626
1966210 4774246 2101739
1734470 3294897 1581002
2882006 3452884 557354
With openblas 0.3.31 (or commit 02dc625), the program outputs this:
1403 1215 883 235
434 1903 624 10
740 305 1196 326
718 133 878 1633
146 1851 942
940 1327 503
852 696 364
1568 1701 130
146 1851 942
940 1327 503
852 696 364
1568 1701 130
I was able to bisect the issue down to #5450, so I believe the SME1 implementation is to blame.
This issue came up because of a test failure in https://github.com/linbox-team/linbox/blob/master/tests/test-blas-domain.C. This was tested on an M1 Pro MacBook Pro running NixOS 26.05.
Activity
martin-frbg commentedon Apr 19, 2026
Hmm, I don't think an M1 should be running the SME code at all ?
Liamolucko commentedon Apr 19, 2026
Interesting. Perhaps the dummy implementation is being invoked for some reason? For what it's worth, the same test is also failing on Ampere Altra machines in NixOS's CI (although I can't verify that it's for the same reason): https://hydra.nixos.org/build/325315833
I can try to double-check exactly which implementation in being invoked later.
martin-frbg commentedon Apr 19, 2026
Weird, this works fine under MacOS but is indeed broken on Asahi Linux. I'll try to look into it later today.
martin-frbg commentedon Apr 19, 2026
Some kind of miscompilation apparently - when I put a single printf in the dummy code path, STRMM suddenly returns the correct result (and doesn't print what I put in the printf either) ...
Liamolucko commentedon Apr 19, 2026
That's strange, for me it's broken on both macOS and Asahi (I only switched to testing on Asahi so I could use
rr).Although I only ever tested 0.3.31 on macOS, not HEAD - testing now.I can also reproduce it with HEAD on macOS. It could also be a compiler version difference, since I'm using nixpkgs' clang 21 rather than macOS's clang 17.martin-frbg commentedon Apr 19, 2026
Compiler probably plays a role, but I've only had time for a quick test on the two M1 minis that are made available through the GCC Compile Farm. Now it's family function instead of BLAS function for me until late in the evening
dasergatskov commentedon Apr 19, 2026
I can confirm this on Raspberry Pi5 / Ubuntu 26.04 with both clang and gcc.
martin-frbg commentedon Apr 22, 2026
Turns out the error "only" affected DYNAMIC_ARCH builds, cause was a quick return inserted in the wrong place that had replaced the intended target of the check for an SME-capable cpu. Same silly bug was also present in the SSYMM code path
openblas: 0.3.32 -> 0.3.33
openblas: 0.3.32 -> 0.3.33
openblas: 0.3.32 -> 0.3.33
openblas: 0.3.32 -> 0.3.33
openblas: 0.3.32 -> 0.3.33