The clat1 test fails on my computer. This is with both gcc 4.1 and 4.3, both with and without SSE, and both Debug and Release mode. On the other hand, the test succeeds on Gael's computer. All other BLAS tests work.
The problem seems to be in the interface of Fortran with C code. The following GDB session shows that the arguments are correct when Fortran calls the C function cdotc(), but when I step into cdotc(), the arguments are shifted.
My first guess would be that the issue is the COMPLEX return value of CDOTC. The cblat1 test seems to be the only test that covers a BLAS function returning a COMPLEX and there are apparently different calling conventions in this case, see http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html
I checked that the Fortran and C++ compiler have the same version number. I did not set any flags for the Fortran compiler.
(gdb) break cblat1.f:493
Breakpoint 1 at 0x804967d: file /home/amsta/jitse/scratch/eigen-official/blas/testing/cblat1.f, line 493.
Starting program: /scratch/1/users/jitse/eigen-official/build/blas/testing/cblat1
Complex BLAS Test Program Results
Test of subprogram number 1 CDOTC
Breakpoint 1, check2 (sfac=@0x804b880)
493 CDOT(1) = CDOTC(N,CX,INCX,CY,INCY)
Current language: auto; currently fortran
(gdb) print N
$1 = 0
(gdb) print INCX
$2 = 1
(gdb) print INCY
$3 = 1
(gdb) print &N
$4 = (PTR TO -> ( integer(kind=4) )) 0x804ce44
(gdb) print &CX
$5 = (PTR TO -> ( complex(kind=4) (7))) 0xbfb1e080
(gdb) print &INCX
$6 = (PTR TO -> ( integer(kind=4) )) 0x804ce48
(gdb) print &CY
$7 = (PTR TO -> ( complex(kind=4) (7))) 0xbfb1e048
(gdb) print &INCY
$8 = (PTR TO -> ( integer(kind=4) )) 0x804ce4c
cdotc_ (n=0xbfb1e080, px=0x804ce48, incx=0xbfb1e048, py=0x804ce4c,
59 if(*n<=0) return 0;
Current language: auto; currently c++
Indeed, there are various conventions to return COMPLEX. The safest is to simply write a small fortran wrapper to CDOTC calling a version returning the result in an argument.
-- GitLab Migration Automatic Message --
This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/189.