LAPACK/BLAS from FORTRAN on 10.6

Dear all,

since updating to 10.6, I’ve been struggling with strange crashes in connection with LAPACK/BLAS routines used in my C++ code, when using the Apple LAPACK and BLAS. They are strange in this sense, that I get a “Bus error” in a reproducible fashion, however depending on whether optimization was. Further, even adding an innocent statement such as cout << “Hi” may prevent the crashes – which probably means that there is some subtle memory corruption issue. Up to now, it’s hard for me to tell if it’s my own fault, or Apple’s, but the same code runs fine under a variety of Linux machines. (Desperately waiting for valgrind on 10.6 …)

Anyway, during my search I finally found a reproducible problem (not susceptible to optimization). Consider the following Fortran code:

PROGRAM TEST

COMPLEX*16 A(1), B(1),C
COMPLEX*16 ZDOTC
EXTERNAL ZDOTC

A(1)=1;
B(1)=2;

C=ZDOTC( 1, A, 1, B, 1 )

WRITE (*,*) C

END

(It is essentially just a complicated way of calculating A(1)*B(1))
If I compile this with gfortran (4.5 from hpc.sourceforge.net) or g95 (current version from www.g95.org) and link against the Apple BLAS (-lblas), I always get a Bus error (gfortran) or segfault (g95) at C=ZDOTC …

Note that this does not happen if I use the manually compiled version of BLAS from netlib.org.

I was wondering if anybody else could reproduce this problem, just to make sure that I didn’t overlook something simple …

MAC FIX

This seems to be a problem with the underlying definition interface between the fortran and c routines. I seem to remember running into this before when I compiled SLaPACK a couple of years ago. I will dig up my notes that provided a work around.

If I try the fortran code above, I get the same crash. However, if one uses the strictly C interface and the code snippet

#include ‘<‘Accelerate/Accelerate.h’>’
#include ‘<‘stdlib.h’>’
#include ‘<‘stdio.h’>’

int main()
{
__CLPK_doublecomplex a[1],b[1],c;
a[0].r = 1;
b[0].r = 2;
a[0].i = 0;
b[0].i = 0;

cblas_zdotc_sub(1,a,1,b,1,&c);

fprintf(stderr,”%g,%g\n”,c.r,c.i);
return(0);
}

Then there is no problem. Again, this is likely to be caused, not by the libraries, but by the odd way they are defined for fortran from the c-versions. As Fortran is not the actual code used for the accelerated versions of lapack and blas furnished by apple, I’m not surprised. I do know that in the end I used ATLAS instead of apple’s version to compile SLaPACK. It proved slightly faster and worked.

Hope this helps.