<div dir="ltr">yes, exactly that's what I imagined. Both amd64 and s390x builds use the reference blas from libblas-dev. However, on s390x the blas package behaves as intel-type while on amd64 it behaves as gnu-type:<br><br><div><img src="cid:ii_mqgh6slk0" alt="image.png" width="578" height="69"></div><div><br></div><div>GetFEM's <a href="http://configure.ac">configure.ac</a> does the only reasonable thing, it detects the ABI of the linked BLAS and adapts itself to it by setting GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT. <br></div><div><br></div><div>Going beyond this specific bug, the main issue is that BLAS has an ambiguous API/ABI. What I am pointing out is that AFAIK update-alternatives cannot deal with such ambiguities. Right?<br><br></div><div>At least for mkl, it leads to errors as reported in <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732</a> , but based on the confb.cpp test results shown by Drew, I would not be surprised if there are more undiscovered bugs related to complex number blas.</div><div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 16 Jun 2026 at 11:21, Drew Parsons <<a href="mailto:dparsons@debian.org">dparsons@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Source: getfem<br>
Followup-For: Bug #1133815<br>
<br>
To get some more context, I ran the <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> tests standalone on<br>
the s390x porterbox<br>
<br>
confb.cpp<br>
-------------------------------------<br>
#include <cstdio><br>
#include <complex><br>
#if defined(GMM_USE_BLAS64_INTERFACE)<br>
#define INT long<br>
#else<br>
#define INT int<br>
#endif<br>
extern "C" {<br>
void cdotu_(std::complex<float>*, const INT*, const std::complex<float>*, const INT*,<br>
const std::complex<float>*, const INT*);<br>
}<br>
int main() {<br>
const INT one=1;<br>
std::complex<float> x(1.,2.), y(1.,-2.), result;<br>
cdotu_(&result, &one, &x, &one, &y, &one);<br>
printf("result (bad C)=%g + %gi\n", result);<br>
printf("result (complex comp)=%g + %gi\n", real(result), imag(result));<br>
printf("result.real()=%g\n", result.real());<br>
printf("result.real()-5.=%.20f\n", result.real()-5.);<br>
printf("fabs(result.real()-5.)=%.20f\n", fabs(result.real()-5.));<br>
printf("fabs(result.real()-5.)< 1e-8 = %d\n", fabs(result.real()-5.)<1e-8);<br>
printf("returning %d\n", (fabs(result.real()-5.) < 1e-8) ? 0 : 1);<br>
return (fabs(result.real()-5.) < 1e-8) ? 0 : 1;<br>
}<br>
-------------------------------------<br>
<br>
$ g++ -o confb confb.cpp -lblas<br>
<br>
Executing on s390x:<br>
$ ./confb <br>
result (bad C)=0.0078125 + 0.00781251i<br>
result (complex comp)=5 + 0i<br>
result.real()=5<br>
result.real()-5.=0.00000000000000000000<br>
fabs(result.real()-5.)=0.00000000000000000000<br>
fabs(result.real()-5.)< 1e-8 = 1<br>
returning 0<br>
<br>
<br>
The issue is that result.real() returns 5 on s390x, which apparently<br>
is the same as Intel fortran.<br>
<br>
By contrast result.real() returns 0 on amd64, so the test in<br>
<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> identifies amd64 as gnu-type not intel-type.<br>
Executing on amd64:<br>
$ ./confb<br>
result (bad C)=0 + 6.95048e-310i<br>
result (complex comp)=0 + 0i<br>
result.real()=0<br>
result.real()-5.=-5.00000000000000000000<br>
fabs(result.real()-5.)=5.00000000000000000000<br>
fabs(result.real()-5.)< 1e-8 = 0<br>
returning 1<br>
<br>
I don't think the BLAS implementations or debian blas alternatives are<br>
the problem. This is the reference blas (libblas-dev). You might<br>
argue there's a misconfiguration in the BLAS packages (or in gfortran)<br>
for s390x. But BLAS otherwise seems to be working fine, we're not<br>
seeing other BLAS errors coming from s390x.<br>
<br>
The difference seems to be way that getfem is using BLAS,<br>
which evidently requires arch-specific handling. Since this<br>
difference is reflecting in the headers via the definition of<br>
GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT, we've got the situation leading<br>
to this bug report.<br>
<br>
The difference appears to be real for getfem, not a bug (unless someone can<br>
identify an s390x bug in BLAS or gfortran).<br>
In that case dropping the multiarch field is best, which Konstantinos<br>
is doing in salsa MR.<br>
<br>
-- <br>
To unsubscribe, send mail to <a href="mailto:1133815-unsubscribe@bugs.debian.org" target="_blank">1133815-unsubscribe@bugs.debian.org</a>.<br>
</blockquote></div>