see Jason's answer in November:
The problem is that ESSL BLAS routines do not call the XERBLA error
handler. (IBM guys like to be a little bit original from time to time.)
The BLAS tester performs wrong calling sequence on the BLAS routines and
then tests that the XERBLA error handler is called with the correct
routine name and the correct error information.
What is happening with ESSL is that when the tester is making non conform
calling sequences to the BLAS, ESSL-BLAS complains, and the tester
complains ... A total mess.
Well so either as Jason has suggested you contact IBM and tell them that
having a call to XERBLA from ESSL so that you can trap error messages
would be really useful or in (for example) sblat2.in there is FLAG TO TEST
ERROR EXITS. Just set it to F. (I have never tried but this should work,
would be glad if you have time to try.)
On Wed, 24 Jan 2007, Dr.-Ing. Ingo D. Rullhusen wrote:
the BLAS test included in LAPACK 3.1.0 failed on AIX own BLAS:
mantis:/ha/rull/tmp/lapack-3.1.0/BLAS$ cat SBLAT2.SUMM
TESTS OF THE REAL LEVEL 2 BLAS
THE FOLLOWING PARAMETER VALUES WILL BE USED:
FOR N 0 1 2 3 5 9
FOR K 0 1 2 4
FOR INCX AND INCY 1 2 -1 -2
FOR ALPHA .0 1.0 .7
FOR BETA .0 1.0 .9
ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN 16.00
RELATIVE MACHINE PRECISION IS TAKEN TO BE 1.2E-07
SGEMV : 2538-2016
The form (ARG NO. 1) of a matrix must be 'N', 'T', or 'C'.
SGEMV : 2538-2099
End of input argument error reporting. For more information, refer to
Engineering and Scientific Subroutine Library Guide and Reference
SGEMV : 2538-2604
Execution terminating due to error count for error number 2099.
SGEMV : 2538-2605
Message summary: 2016 - 1
SGEMV : 2538-2605
Message summary: 2099 - 1
The AIX version seems to exit directly on the wrong calls of type
CALL SGEMV( '/', 0, 0, ALPHA, A, 1, X, 1, BETA, Y, 1 )
so that no error handling is possible.
Lapack mailing list