Tracking down an error in the

The sanity tests only run the LAPACK testers in this directory. The LAPACK routines depend on the BLAS, so ignore errors in lapack testers until all the BLAS pass with no error. If you have errors in LAPACK but the BLAS pass all tests, then you have to hunt for the error in the LAPACK routines.

First, rule out that it's not a problem in the BLAS that is just not showing
up in the BLAS testing. Get yourself a reference BLAS library, as explained
in Section . Then, set your `Make.inc`'s `BLASlib`
macro to point to the created reference BLAS library. Then, you need to
compile a library that uses ATLAS's lapack routines, but the reference
BLAS. This can be done by compiling the same executable name with `_sys`
suffixed. For instance, if you were running the LU tester, `xdlutst`,
you would say `make xdlutst_sys`, and then run this executable with
the same input.

If the error goes away, then the error is really in the ATLAS BLAS somewhere. I then usually look at the LAPACK routine and tester in question to find out what its BLAS dependencies are, and manually link in the reference BLAS object files until I find the exact BLAS causing the problem. Usually once you know what routine causes the prob, you can reproduce the error with the BLAS tester (i.e. you need a IDAMAX call with N=12, incX=82).

If the error still persists using ATLAS's LAPACK and the Fortran77 BLAS,
the next trick is to do LAPACK just like the BLAS: download and compile the F77
LAPACK from netlib (`www.netlib.org/lapack/lapack.tgz`). You then
set your `Make.inc's` `FLAPACKlib` to point to your Fortran77 lapack
library. You then suffix the base executable name with `F_sys` (eg., for
LU again, you would do `make xdlutstF_sys`), and
you will get a tester linked against the Fortran77 BLAS *and* LAPACK.
If this also shows to be in error, there is an error in the tester, or in
the compiler. Try turning down compiler optimization to rule in or out
compiler errors.

Clint Whaley 2012-07-10