On 31-Oct-2007, John Swensen wrote:
| You were right. If I try to print out retavl, I still get an "Illegal
| instruction" error. So I guess I am not exactly sure the solution to
| this. I am using the vecLib that is provided by Apple and the gfortran
| that is compiled using fink. Is it as easy and rebuilding and
| re-installing gfortran, or is there some other underlying problem that
| will prevent even that from working? Will installing a version of
| BLAS/ATLAS manually with the fink supplied Fortran fix the calling
| convention problem? Any suggestions on how to go forward, other than
| just inhibiting the use of the system BLAS and using the functions
| provided by Octave?
Yes, one possibility is to fall back to the reference LAPACK+BLAS
libraries when the test fails. Unfortunately, then you lose the
speedup of having an accelerated BLAS+LAPACK library.
You could use LAPACK+BLAS+ATLAS instead, and compile it in a way that
is compatible with gfortran.
You can try building all the Fortran bits of Octave with "gfortran
-ff2c". This is not a perfect solution because there may be other
Fortran libraries that you want to use that have been compiled with
gfortran without -ff2c.
You could try compiling only libcruft/blas-xtra/xzdotu.f and
libcruft/lapack-xtra/xzlange.f with "gfortran -ff2c".
Another possibility is to avoid calling the zdotu and zlange
functions. For example, instead of wrapping zdotu in xzdotu.f, simply
copy the guts of zdotu.f to xzdotu.f so that instead of
subroutine xzdotu (n, zx, incx, zy, incy, retval)
double complex zdotu, zx(*), zy(*), retval
integer n, incx, incy
retval = zdotu (n, zx, incx, zy, incy)
return
end
we have
subroutine xzdotu (n, zx, incx, zy, incy, ztemp)
c
c forms the dot product of two vectors.
c jack dongarra, 3/11/78.
c modified 12/3/93, array(1) declarations changed to array(*)
c
double complex zx(*),zy(*),ztemp
integer i,incx,incy,ix,iy,n
ztemp = (0.0d0,0.0d0)
zdotu = (0.0d0,0.0d0)
if(n.le.0)return
if(incx.eq.1.and.incy.eq.1)go to 20
c
c code for unequal increments or equal increments
c not equal to 1
c
ix = 1
iy = 1
if(incx.lt.0)ix = (-n+1)*incx + 1
if(incy.lt.0)iy = (-n+1)*incy + 1
do 10 i = 1,n
ztemp = ztemp + zx(ix)*zy(iy)
ix = ix + incx
iy = iy + incy
10 continue
zdotu = ztemp
return
c
c code for both increments equal to 1
c
20 do 30 i = 1,n
ztemp = ztemp + zx(i)*zy(i)
30 continue
return
end
Likewise for the zlange function from LAPACK. Since these are the
only two complex-valued Fortran functions that are called from Octave,
I think this will solve the problem for Octave. But it won't fix the
problem for other code you might have that mixes the convention, so
people still need to be aware of this problem.
Yet another possibility is for Octave to start using the cblas/clapack
interface instead of calling the Fortran functions directly. But I'm
not sure whether that is any more portable. For example, is there a
cblas/clapack interface to Apple's vecLib?
I see that cblas uses the same trick of wrapping Fortran functions in
Fortran subroutines to avoid the general problem of differences in
calling conventions. But at leasst in that case, we could probably
safely assume that the wrapper subroutine and the underlying functioon
have been compiled with the same compiler, so there would be no risk
of mismatch there.
Unfortunately, I think we will have to work around this problem in
Octave.
Maybe the best thing to do for 3.0 is to make the change to xzdotu.f
and zxlange.f outlined above and drop the configure test. After 3.1
we can consider the switch to the cblas interface or some other better
fix.
Comments?
jwe