fixesd inconsistencies between 'L' and 'U' parts in (z,c)lahef.f, added an IF check to 'U' part IF(KP.GT.1) where column interchange occurs

fixes to comments in *zlasyf_rook.f

fixes to comments in *lasyf_rook.f

fixes to comments in *lasyf_rook.f

removed extra characters after ZERO

Add xlacn2 for PLASMA team

fixes to documentation in clahef.f and zlahef.f

fixes to comments in *lasyf_rook.f

fixes to documentation in *lasyf.f, *lasyf_rook.f

patch from Mathworks that fixes convergence problem with some particular pencils in xGGEV

* added check for NaN after the norm of each block of H is computed
* if NaN is detected, returns with INFO=-6 (H is the 6th parameter)
* fixes problem found by Alexander Kobotov at Intel where a NaN in H can cause an infinite loop:

  http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=3928

Simplify description of workspace requirement
Reported by Simon on Oct 8th on LAPACK forum : http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=3951

The size of the workspace for DGESDD for JOBZ = 'S' or 'A' has been changed in LAPACK 3.4.2, and is set by LWORK. The current description of LWORK reads:

LWORK >= 3*min(M,N) +
         max(max(M,N),4*min(M,N)*min(M,N)+3*min(M,N)+max(M,N)).

In the second line, both arguments of max contain max(M,N), and so the the function is redundant - the second argument will always be realised.
So the description could be simplified to:

LWORK >= 3*min(M,N) +
         4*min(M,N)*min(M,N)+3*min(M,N)+max(M,N)

or further simplified to

LWORK >= min(M,N)*(6+4*min(M,N))+max(M,N)

Add ilaver to LAPACKE

Correct typo found by Elena Ivanova, Oracle.

See http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=3612

Corrected bug that occurs when V is stored in backwards order: previously, the scan for zero rows or columns at the _end_ of V can result in the trunctation of the unit triangular part of V.  The correction replaces the LASTV in the DIRECT='B' cases with the full length, which is either M or N, which then keeps the full K-by-K unit triangular portion of V.  Another approach, which could be applied in a future revision, is to add new routines to compute the first non-zero row and non-zero column of a matrix, and store this index in FIRSTV, and run the loops and matrix multiplications from FIRSTV:M and FIRSTV:N where appropriate.

reverting to previous version, which is correct

fixed logic error that corrects bug found by Duncan Po at Mathworks

Correct comments and Doxygen generation following comments from Sa-Lin Cheng Bernstein sent to lapack mailing list on August 9th 2012

While looking at the new lapack version (v3.4.1) and going through the routines on http://www.netlib.org/lapack/lapack_routine/, we found some errors and thought that we should report them. Below is the list of the errors.

====================================================================
(1) Should be "\ingroup complex16OTHERsolve" and not "\ingroup complex16OTHERcomputational" because they are driver routines; in addition, in the line just below SUBROUTINE <routinename>, it should be driver routine:
sgtsv.f
sgtsvx.f
sptsv.f
sptsvx.f
dgtsv.f
dgtsvx.f
dptsv.f
dptsvx.f
cgtsv.f
cgtsvx.f
cptsv.f
cptsvx.f
zgtsv.f
zgtsvx.f
zptsv.f
zptsvx.f

(2) Should be "\ingroup complex16SYsolve" and not "\ingroup complex16OTHERcomputational" because they are driver routines; in addition, in the line just below SUBROUTINE <routinename>, it should be driver routine:
ssysvxx.f
dsysvxx.f

(3) Should be "\ingroup realOTHERcomputational" and not ""\ingroup auxOTHERcomputational":
spttrf.f

(4) Should be "\ingroup doubleOTHERcomputational" and not ""\ingroup auxOTHERcomputational":
dpttrf.f

(5) Should be "symmetric matrix" and not "Hermitian indefinite matrix" in "\par Purpose:"
ssytri2.f
dsytri2.f
csytri2.f
zsytri2.f

(6) Should be "\ingroup realGEsing" and not "\ingroup realGEcomputational":
sgejsv.f
dgejsv.f

Correct comments in
SRC/sgeev.f
SRC/dgeevx.f
SRC/dgeev.f
SRC/sgeevx.f

Reported by Konstantinos Kafoysas (Beta CAE Systems S.A., Greece) on Thu Aug
9th, 2012 through LAPACK mailing list.

> In the comments of dgeev function
>
> *  The left eigenvector u(j) of A satisfies
> *                u(j)**T * A = lambda(j) * u(j)**T
> *  where u(j)**T denotes the transpose of u(j).
>
> u is supposed to satisfy u(j)**H * A = lambda(j) * u(j)**H

error in comment detected by Mathieu (PLASMA)

Routine affected: [CZ]HEGST et [CZ]HEGS2,
B is IN in comment, but in the code, B is actually changed, but after restored.
Here is the code portion that is to blame. [CZ]HEGS2

00203                IF( K.LT.N ) THEN
00204                   CALL ZDSCAL( N-K, ONE / BKK, A( K, K+1 ), LDA )
00205                   CT = -HALF*AKK
00206                   CALL ZLACGV( N-K, A( K, K+1 ), LDA )
00207                   CALL ZLACGV( N-K, B( K, K+1 ), LDB )
00208                   CALL ZAXPY( N-K, CT, B( K, K+1 ), LDB, A( K, K+1 ),
00209      $                        LDA )
00210                   CALL ZHER2( UPLO, N-K, -CONE, A( K, K+1 ), LDA,
00211      $                        B( K, K+1 ), LDB, A( K+1, K+1 ), LDA )
00212                   CALL ZAXPY( N-K, CT, B( K, K+1 ), LDB, A( K, K+1 ),
00213      $                        LDA )
00214                   CALL ZLACGV( N-K, B( K, K+1 ), LDB )
00215                   CALL ZTRSV( UPLO, 'Conjugate transpose', 'Non-unit',
00216      $                        N-K, B( K+1, K+1 ), LDB, A( K, K+1 ),
00217      $                        LDA )
00218                   CALL ZLACGV( N-K, A( K, K+1 ), LDA )

Commit Brian Sutton new CS Decomposition routines.

All the routines from the SRC folder have been updated to integrate the current Doxygen layout.
Everything seems to be fine, all tests passed without problem.

added NaN check to prevent NaN's from being skipped in accumulation

matrix norms now consistently return nan when input matrix contains a nan;
previously, this was (usually) only the case for the 'F' norm

Add make.in for pgf95 compiler

Correct bug0096 reported by Joseph Young from Sandia.
Followed recommendation, use the existing sorting code.

Report sent to LAPACK mailing list on June 26th 2012

From Joseph:
>     There appears to be an inconsistency and possible bug in the dstemr
> implementation.  When calculating the eigenvalues of a matrix, the
> returned eigenvalues are supposed to be returned in ascending order.
> Although this appears to be the case for N >= 3, it does not appear to
> be the case for N=2.  I believe this happens because the dstemr routine
> has special cases for N=0,1, and 2, which immediately return after their
> computation.  Because these cases return immediately, they do not call
> the sorting routines around line 723 (in LAPACK version 3.4.1).  As
> such, a simple fix would be to have the N=2 case call this sorting code
> rather than returning.

Add Brief description for auxiliary routines

Added fix to prevent dividing by T when T=0 provided by Alexander Kobotov of Intel.

Correct a problem reported by Keita Teranishi from CRAY on May 18th 2012
Confirmed and Corrected by Julie on May 21st 2012

====================================
EMAIL:
We would like to report a bug in {S,D}SYEVR and {C,Z}HEEVR  routines.  This bug causes writing two different data in the same address in IWORK, potentially producing wrong answers.
The bug description is provided in the bottom of the email.  Please let us know, if you have any questions.

Thank you,

Line 543 in {S,D}SYEVR:
Line 717 on {C,Z}HEEVR:

=== Code Starts here==
      INDISP = INDIBL + N
*     IWORK(INDIFL:INDIFL+N-1) stores the indices of eigenvectors
*     that corresponding to eigenvectors that fail to converge in
*     DSTEIN.  This information is discarded; if any fail, the driver
*     returns INFO > 0.
      INDIFL = INDISP + N
*     INDIWO is the offset of the remaining integer workspace.
      INDIWO = INDISP + N  <- -- It is suspicious.
=====End of the Code=========

I think this should be INDIWO = INDIFL+N.  Otherwise, subsequent {S,D}STEIN call takes the same address for IWORK(INDIWO) and INWROK(INDIFL).
         CALL DSTEIN( N, WORK( INDD ), WORK( INDE ), M, W,
     $                IWORK( INDIBL ), IWORK( INDISP ), Z, LDZ,
     $                WORK( INDWK ), IWORK( INDIWO ), IWORK( INDIFL ),
     $                INFO )

====================================

added missing comma, thanks to Lee Killough at ANL

Correct a minor problem in comments sent by Alexander Kobotov

One more minor notice:
- In sgsvj0.f and sgsvk1.f: EPS and SFMIN become INTEGER in description whereas these are actually REAL.

Fix lange routine.
   /* Allocate memory for working array(s) */
   if( LAPACKE_lsame( norm, 'e' ) || LAPACKE_lsame( norm, 'f' ) ) {
       work = (double*)LAPACKE_malloc( sizeof(double) * MAX(1,m) );
       if( work == NULL ) {
           info = LAPACK_WORK_MEMORY_ERROR;
           goto exit_level_0;
       }
   }

This is wrong, it is actually the opposite. Only the inf norm needs a workspace.

Thanks Mathieu for catching this!

Commit patch sent by Sébastien Fabbro to enable LAPACKE built without LAPACK.
The patch has been modified a little by Julie as there were some minors problems.
This also fix the BUILD_TESTING=OFF option problem reported by Marcin on lapack mailing list.

From Sébastien:
Here is a patch to compile lapacke with CMake using an already
existing optimized lapack library instead of forcing the build of the
included one in the tar ball. It applies to the latest lapack svn
trunk.

Update CMAKE version requirement and remove FindBLAS module that is now include inside CMAKE

Minor modification for ctest build template

Fix small problem detected by user Yao Toa. sent to the LAPACK mailing list on April 23th 2012
It seems that this one has been around forever

============

hi.

i found a subtle difference between dsyevd.f and ssyevd.f when using lapack 3.4.1.

dsyevd updates LOPT after calling dsytrd and dlacpy. but those codes are not visible in ssyevd.f, cheevd.f and zheevd.f.

pls refer to line 329, 344 in dsyevd.f.

i wonder whether those codes are necessary, because dsyevd has precalculated LOPT with at least 1+6*N+2*N**2.

if those codes must be there, why not for ssyevd?

thanks in advance.

Yao Tao

modified exceptional shift for complex versions - solves problem of nan's appearing on some platforms, most notably IBM/XLF, causing an infinite loop in xLARTG (which also should be fixed by enforcing a max iteration count when computing SCALE)

Fix problems in comments found by Alexander Kobotov

Just taking a quick look on the new release I noticed some minor issues there, which probably caused by a generation script:
- If you explore diff for files (c/z)gbrfsx, cgbsvx, cgbsvxx, cheequb, clanhf, zheequb you could find that number of datatype descriptions in documentation were changed to incorrect one (DOUBLE PRECISION instead of COMPLEX, or COMPLEX*16 instead of just COMPLEX).
+ cunbdb has CMPLX instead of COMPLEX for X12 parameter.
+ zggevx RWORK become REAL instead of correct DOUBLE PRECISION
- Number of files got following string "/ output)", which seems meaningless. Just grep for it.

Fix XLF flags that were causing test zgg to hang

put FOUR parameter back since it is used in this routine

rearrange the test (Julien prefers it that way)

Update date and revision number

Correct bug sent by NAG people

Got a new bug for you! Mick Pont found this problem in DLAED6. The code in question is the 40 loop - when DSCALE(I)=TAU you get a divide by zero (rare in practice). This can cause some compilers to immediately stop, e.g. the Sun compiler.

Mick proposed solution is below:

        DO 40 I = 1, 3
           IF (DSCALE( I ).NE.TAU) THEN
              TEMP = ONE / ( DSCALE( I )-TAU )
              TEMP1 = ZSCALE( I )*TEMP
              TEMP2 = TEMP1*TEMP
              TEMP3 = TEMP2*TEMP
              TEMP4 = TEMP1 / DSCALE( I )
              FC = FC + TEMP4
              ERRETM = ERRETM + ABS( TEMP4 )
              DF = DF + TEMP2
              DDF = DDF + TEMP3
           ELSE
*              On rare occasions dscale(i) can be exactly equal to
*              tau, leading to division by zero. If no trap occurs,
*              there is no problem; the quantities above all overflow
*              and the test on abs(f) below sends you to the end
*              with good results. If a trap occurs, though, the
*              user program will stop. Avoid that happening by
*              jumping directly out.
              GO TO 60
           END IF
  40    CONTINUE

This seems to work OK in our testing.

modified exceptional shift strategy so that QZ now works for various pencils (see netlib.org/lapack/Errata/vrac/lapack_known_issues.html)

Update version number

Fix small issue with lapacke built

Add -qnosave option for xlf compiler (Thanks Rodney)

Follow up to rev r1130

Fix bug bug0088 reported by Mike Pont from NAG on the forum
(see http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=2893)

Actually there were a lot of problems regarding arguments checking.
I tried to correct most of them.

Apply the fix propose to all x[he/sy]rfsx.f routines
- Use IGNORE_CWISE as suggested to prevent use of unitialize variable PARAMS

I also appied the previous TESTING fix to all routines

INFO has new value in ZHERFSX (see description of INFO between ZHESVX and ZHESVXX)
This is set on line 634 (IF ( INFO .LE. N ) INFO = N + J) of zherfsx.f
And this is not handled by the testing LIN/zdrvhex.f
I just add  .AND. INFO.LE.N at line 638 to avoid raising an error when INFO = N + J

At the moment, I would recommand a further look at those routines.
ZHE, ZSY led to 182 Tests failing to pass the threshold
and the same for complex

better than before, but still....

removed comment regarding A being modified and restored - this is no longer the case with the changes made to xLARFT

Remove unused variables

Remove unused parameters

added code to handle N=1 case to fix divide by zero problem that occurs
when the single (diagonal) element is negative

see: http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01195.html

Fix call to GEMQRT (no lwork) and lwork declarations

Fix External Subroutines declarations

Add the python script for LAPACK Summary output to CTEST

changed SVD test threshold to 50.0 and removed SEP test for matrix type 9 so that all tests pass

changed weights so that the badly conditioned tests (which always fail) are avoided for SXV, DXV, CXV, ZXV.

Fix provided by Hong Bo Peng for bug0026

Undoing unvoluntary change commited in 1237

Following Mathieu's request, some part of lapacke.h were moved to lapacke_utils.h
(the definition of ABS, MAX, MIN, etc...)
Those were conflicting with PLASMA internal definitions.

LAPCKE Routines are now just including lapacke_utils.h which in turn includes lapacke.h

Correct problem in Workspace calculation

Correct bug 0090 Need to unscale if necessary when there is an error in DHGEQZ (QZ iteration failed)

 * bug report by Hong Bo Peng Sandgren, on 03-19-2012.
 * See link:http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01257.html[LAPACK Mailing list msg 01257]

I am doing some work with DGGEV. When I check the return msg and the actual code, I found something may be wrong. Here is part of comments in the header of DGGEV.F.

*  INFO    (output) INTEGER
*          = 0:  successful exit
*          < 0:  if INFO = -i, the i-th argument had an illegal value.
*          = 1,...,N:
*                The QZ iteration failed.  No eigenvectors have been
*                calculated, but ALPHAR(j), ALPHAI(j), and BETA(j)
*                should be correct for j=INFO+1,...,N.
*          > N:  =N+1: other than QZ iteration failed in DHGEQZ.
*                =N+2: error return from DTGEVC.

When INFO = 1...N, there is an error in DHGEQZ (QZ iteration failed). From the code, we can see it jumps to label 110 then set WORK(1) and return.
But in case of we scaled the matrix, we still need to undo scale for the output array ALPHAR, ALPHAI and BETA for those values j=INFO+1,...,N.

In DGEEVX, we can see that it jumps to label 50 in case of DHSEQR failure and then undo scale before return.

Add csyr and zsyr needed by the PLASMA project

modified so that V is [in] only instead of [in/out]

Change CMAKE configuration for LAPACKE

CMAKE now can find the Fortran Mangling automatically (no need of extra flags)
with the module FortranCInterface and create the necessary header.
Needed to make some adjustements with the routine name.
Added a file lapacke_mangling_with_flags.h that is used with Makefile build

lapacke.h now requires lapacke_mangling.h
 - the file is created by CMAKE if CMAKE is used
 - the file is copied from lapacke_mangling_with_flags if Makefile is used

Fix Makefile in LIN

Fix Typo

Fixed problem with optimizer breaking error checking, now using F90 EPSILON intrinsic.
Thanks to Harald Anlauf for providing the solution.

replaced calculation of EPS with F90 call to EPSILON intrinsic

Update CMAKE build

Fixed QRT routine testing

typo

added a comment to *chksy_rook.f

introduced CALL XLAENV( 2, 2 ) in zchksy.f and  cchksy.f in order to make them uniform with schksy.f and dchksy.f and *chksy_rook (it was discussed with Julien in an email)

added sdrvsy_rook.f cdrvsy_rook.f zdrvsy_rook.f to LIN/CMakeLists.txt

small fixes, removed unused varibales in  ddrvsy_rook.f zdrvsy_rook.f sdrvsy_rook.f

added a test for double precision complex SV driver for symmetric indefinite matrices with rook pivoting

added a test for double precision complex SV driver for symmetric indefinite matrices with rook pivoting

Add an option LAPACKE_WITH_TMG that will generate the LAPACKE with the TMG routines needed in plasma (by default regular LAPACKE with only LAPACK routines

Add the test for single precision driver routines for symmetric indefinite matrices with rook pivoting in CMAKE

added the test for single precision driver routines for symmetric indefinite matrices with rook pivoting

Fix LAPACKE makefile to only include XBLAS routine if USEXBLAS is defined

Adding CMAKE Support for LAPACKE.
Now we can generate dll for LAPACK and LAPACKE directly for Mingw so that FORTRAN compiler is longer needed.
Because LAPACKE contains some routines from MATGEN (for PLASMA), LAPACKE will requires the tmglib library.

Add some LAPACK 3.4.0 routines were missing in the CMAKE LAPACK build.

Fix minor problem in some comments...