Source: getfem
Followup-For: Bug #1133815
To get some more context, I ran the configure.ac tests standalone on
the s390x porterbox
confb.cpp
-------------------------------------
#include <cstdio>
#include <complex>
#if defined(GMM_USE_BLAS64_INTERFACE)
#define INT long
#else
#define INT int
#endif
extern "C" {
void cdotu_(std::complex<float>*, const INT*, const std::complex<float>*, const
INT*,
const std::complex<float>*, const INT*);
}
int main() {
const INT one=1;
std::complex<float> x(1.,2.), y(1.,-2.), result;
cdotu_(&result, &one, &x, &one, &y, &one);
printf("result (bad C)=%g + %gi\n", result);
printf("result (complex comp)=%g + %gi\n", real(result), imag(result));
printf("result.real()=%g\n", result.real());
printf("result.real()-5.=%.20f\n", result.real()-5.);
printf("fabs(result.real()-5.)=%.20f\n", fabs(result.real()-5.));
printf("fabs(result.real()-5.)< 1e-8 = %d\n", fabs(result.real()-5.)<1e-8);
printf("returning %d\n", (fabs(result.real()-5.) < 1e-8) ? 0 : 1);
return (fabs(result.real()-5.) < 1e-8) ? 0 : 1;
}
-------------------------------------
$ g++ -o confb confb.cpp -lblas
Executing on s390x:
$ ./confb
result (bad C)=0.0078125 + 0.00781251i
result (complex comp)=5 + 0i
result.real()=5
result.real()-5.=0.00000000000000000000
fabs(result.real()-5.)=0.00000000000000000000
fabs(result.real()-5.)< 1e-8 = 1
returning 0
The issue is that result.real() returns 5 on s390x, which apparently
is the same as Intel fortran.
By contrast result.real() returns 0 on amd64, so the test in
configure.ac identifies amd64 as gnu-type not intel-type.
Executing on amd64:
$ ./confb
result (bad C)=0 + 6.95048e-310i
result (complex comp)=0 + 0i
result.real()=0
result.real()-5.=-5.00000000000000000000
fabs(result.real()-5.)=5.00000000000000000000
fabs(result.real()-5.)< 1e-8 = 0
returning 1
I don't think the BLAS implementations or debian blas alternatives are
the problem. This is the reference blas (libblas-dev). You might
argue there's a misconfiguration in the BLAS packages (or in gfortran)
for s390x. But BLAS otherwise seems to be working fine, we're not
seeing other BLAS errors coming from s390x.
The difference seems to be way that getfem is using BLAS,
which evidently requires arch-specific handling. Since this
difference is reflecting in the headers via the definition of
GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT, we've got the situation leading
to this bug report.
The difference appears to be real for getfem, not a bug (unless someone can
identify an s390x bug in BLAS or gfortran).
In that case dropping the multiarch field is best, which Konstantinos
is doing in salsa MR.
