updated on Tue Apr 19 2011

maintained by Julien Langou, U. Colorado Denver and Julie Langou, U. Tennessee

CLAPACK-3.2.1 errata file

BLACS-1.1.patch3 errata file

ScaLAPACK-1.8.0 errata file

Wishlist

RED means BUG WAS CONFIRMED but IT IS STILL HERE

ORANGE means BUG WAS NOT CONFIRMED

GREEN means BUG WAS CORRECTED :

bug0078 :: DBDSDC problem with orthogonality of U in certain cases

  • bug report sent by duncanpo on April 4th 2011

  • see forum topic 2326

  • decreased EPS by a factor of 0.9 to correct problem with orthogonality of U in certain cases

  • corrected by Rodney on Tue April 7th 2011

bug0077 :: [DS]GESVD Minimum Worksize comments need clarification

  • bug report sent by squartz on Sep 19th

  • see forum topic 2011

  • corrected by Julie on Tue April 5th 2011

bug0076 :: Problem in ?(sy/he)tri2 when nbmax greater than n

  • bug report sent by nmozarto on Mar 4th

  • see forum topic 2223

  • corrected by Julie on Fri March 4th 2011

bug0075 :: not orhtogonal: eigenvectors of a symmetric matrix with DSYEV

  • bug report sent by fabioaffinito on Feb 8th

  • see forum topic 2169

  • corrected by Rodney on Thu March 3rd 2011

  • The bug appears only when the matrix is diagonalized by using the upper half, and when the leading dimension n>200 approx.

  • User gave test program see: here

  • Come from change in version 3.2 [Release Notes]

  • related to 0035

bug0074 :: ?sysv and ?hesv

  • bug report sent by Alexander Kobotov on Feb 8th

  • see forum topic 2168

  • corrected by Julie

  • In LAPACK 3.3 ?(SY/HE)SV are updated to use TRS2. The TRS2 requires WORK(N) to operate, whereas in SV requirements for LWORK just to be >=1. There is no any check in SV if LWORK>=N, the array WORK just passed as it is to TRS2. So if LWORK<N a crash could occur while executing TRS2 due to overuse of allocated workspace.

  • I guess for the case of LWORK<N just previsous Level2 based ?(SY/HE)TRS should be used.

bug0073 :: secondtst.f and dsecnd.f

  • bug report sent by John Tellefson on Feb 7th

  • email sent to lapack mailing list, user provided fix.

  • corrected by Julie

  • We went ahead and remove the dummy subroutine in those timing for the last LAPACK version because we did not find a machine or compiler that still had the problem. I guess we were too optimistic.

  • also committed the "cosmetic" modifications suggested by user as they make the program easier to modify.

bug0072 :: cchkhs.f and zchkhs.f

  • bug report sent by Inge Gutheil on Feb 3rd

  • email sent to lapack mailing list, user provided fix.

  • corrected by Julie

  • Add IF statement to prevent calculation if N=0

bug0071 :: slarre and dlarre

  • bug report sent by Christof Voemel on Jan 31th

  • email sent directly to Julie and Julien, Christof provided fix.

  • corrected by Julien

  • Add a line to prevent TAU from becoming zero

bug0070 :: IWORK dimension is incorrect

  • bug report sent by nmozarto on Jan 27th

  • see forum topic 2156

  • confirmed by Julie and corrected by Brian Sutton

  • The correct dimension is (M-R), in which R is the smallest of P, M-P, Q, and M-Q.

  • An M-by-M matrix is partitioned into a 2-by-2 block structure. The

  • dimensions of the blocks are P-by-Q, P-by-(M-Q), (M-P)-by-Q, and

  • (M-P)-by-(M-Q). IWORK is involved in the permutation of rows or

  • columns of these blocks, and it is the largest block, in terms of

  • number of rows or columns, that determines the size of IWORK.

bug0069 :: sytri2x is writing on other part of A

  • bug report sent by nmozarto on Jan 27th

  • see forum topic 2156

  • confirmed by Julie and corrected by Julie

bug0068 :: Need to add LDA in *sytrs2

  • bug report sent by nmozarto on Jan 27th

  • see forum topic 2157

  • confirmed by Julie and corrected by Julie

bug0067 :: Need to add LDA in *syswapr

  • bug report sent by nmozarto on Jan 24th

  • see forum topic 2150

  • confirmed by Julie and corrected by Julien

  • Need to add LDA in *syswapr routines and update testing to test having LDA

bug0066 :: bugs in {s,d}gejsv

bug0036 :: scaling in xSTEQR, xSTERF

  • bug report sent by Pat Quillen on Fri 24 Jul 2009 to "lapack@cs.utk.edu". "Scaling in xSTEQR, xSTERF"

  • see Pat Quillen’s email, quillen dsteqr.f.

  • Correction: "changed matrix norm to M (max) from I (inf) for scaling of input matrix

  • and added check for zero norm in xSTERF (the xSTEQR already had this check)"

  • confirmed by Rodney and corrected by Rodney

bug0035 :: dlarfb.f and likes

bug0034 :: comments in SSPTRF not correct

  • clarification asked by "sarnath" on Thu Jul 02 2009

  • confirmation of bug by "sarnath" and Julien Langou on Fri Jul 03 2009

  • The statement "JMAX is the column-index of the largest off-diagonal element in row IMAX" is not correct

  • see forum topic 1553

bug0027 :: misleading comment in the header of DGHEQZ, the 2x2 block of the real Schur form are not as claimed

  • reported by Vasile Sima on Tue Jan 27 2009

  • see: email from Vasile

  • more information: more specifically Vasile is reporting that the comments: 

*          [...] H contains the upper quasi-triangular
*          matrix S from the generalized Schur factorization;
*          2-by-2 diagonal blocks (corresponding to complex conjugate
*          pairs of eigenvalues) are returned in standard form, with
*          H(i,i) = H(i+1,i+1) and H(i+1,i)*H(i,i+1) &lt; 0.

are not correct

  • confirmed by Rodney and corrected by Rodney

bug0024 :: the notation A' is confusing for complex matrices. Does A' stand for A transpose of A Hermitian transpose?

  • reported by Clint Whaley early July 2009

  • LAPACK is not consistent in it use of the notation for transpose and Hermitian transpose.

  • The use of LAPACK A' is not consistent with the BLAS useage.

  • We note that the Matlab/Scilab/Octave convention is A' stands for "conjugate transpose" and A.' stands for "transpose".

  • In the Z routines, LAPACK uses the notation A' 669 times, it means "conjugate transpose" most of the time but it means "transpose" a few times (maybe 10 times max, for BLAS-like routines). The notation A*H, A*T, A*N is used 549 times, The notation AT, AN, A^H 19 times. (This is just for the Z routines.)

  • see Julien’s emails

  • vote on the lapackers mailing list: A*T (or AT) and A*H (or AH): Clint Whaley, Jim Demmel, Sven Hammarling, Antoine Petitet, Daniel Kressner A' (for A*H) and A.' for (A*T): Julien Langou (I love to be that supported by the lapackers!)

  • corrected by Julie

bug0022 :: workspace query bug with DGEJSV (when only left or right singular vectors desired)

  • reported by Allin Cottrell on Tue Jan 15 2009

  • confirmed by Julien Langou on Fri Jan 30 2009

  • see forum topic 866

  • all information sent to Zlatko Drmac

  • Corrected by Zlatko Drmac

bug0065 :: workspace queries not being used

  • CONFIRMED

  • bug report by Clint Whaley on October 27th, 2010

  • DGESVD does not perform a workspace query on worker

  • functions such as DGELQF, but rather it hardwires in an assumption as

  • to LQF’s workspace requirements. This means that if LQF is changed,

  • GESVD breaks. This actually happens in ATLAS, because we provide a

  • faster GELQF, which sometimes uses extra workspace. For LAPACK itself,

  • it represents extra dependencies that don’t need to be there.

bug0061 :: zgehrd.f is overflowing

  • CONFIRMED

  • bug report by Victor Liu on Tuesday August 03rd, 2010

  • zgehrd.f is overflowing the maximum size in bytes of the largest array that

  • can be put on the stack with gfortran (⇒ leads ,e.g., to non-reproducible and uncorrect execution

  • of zgeev in multithreaded context

  • lapackers involved in the bug fix process: Julie and Julien Langou and Mathieu Faverge

  • bug fix by Victor Liu on Wednesday August 04th, 2010

  • see forum topic 1930

  • two outstanding issues: (1) how do we go to fix this?, (2) more LAPACK subroutines might be concerned.

bug0057 :: Non-eigenvectors from DGEEV, problem in balancing

  • CONFIRMED

  • bug report sent by Numpy team on April 22nd, 2010

  • see forum topic 1818

  • see follow-up on lapackers on April 22nd from Jim "bug in DGEHRD" "The balancing is choosing to scale some rows/columns by factors like 1e18, which rather amplifies tiny rounding errors in the (presumably correctly) computed eigenvectors of the balanced matrix, when balancing is undone at the end. The expert driver interface dgeevx would let the user disable balancing, until we figure out whether this is a bug or a feature, I’m not sure which."

bug0056 :: Non-orthogonal eigenvectors returned from DSYEVR

  • CONFIRMED

  • bug report sent by Scipy team on April 22nd

  • see LAPACK Mailing list msg 874

  • Confirmed by Rodney on Tue, 17 Feb 2011

  • " I can reproduce similar problems that the user encountered with non-orthogonal eigenvectors when only

  • a few eigenvalues are requested. This also happens with SSYEVR. If I set ABSTOL to SLAMCH(Safe minimum),

  • the problem goes away in SSYEVR, and improves with DSYEVR but does not completely go away."

bug0033 :: failure of zheevd on a specific matrix

bug0032 :: matrix splitting problem with dstebz and sstebz

  • CONFIRMED

  • bug report sent by Phil DeMier (IBM) on Mon 29 Jun 2009 to "lapack@cs.utk.edu". "matrix splitting problem with dstebz and sstebz"

  • see Phil DeMier’s email and Phil DeMier’s test code

  • Confirmed by Rodney on Tue, 17 Feb 2011

bug0028 :: failure of convergence of DHGEQZ for some specific matrix pencils

  • CONFIRMED

  • reported by Vasile Sima on Thu Jan 22 2009

  • see: email from Vasile

  • more information at: see lapack known issues

  • related to bug0026 below

  • Confirmed by Rodney on Tue, 08 Feb 2011

bug0026 :: problem when playing with DGEEV and gfortran optimization flags

  • CONFIRMED

  • reported by Pauli Virtanen (scipy team) on Sat Dec 06 2008 (email to lapack@cs.utk.edu)

  • see: email from Pauli Virtanen see: http://scipy.org/scipy/scipy/ticket/709

  • problem appears to be with an underflow producing alpha=beta=zero eigenvalues for some cases in the above test code

  • it does not depend on the compiler options in later versions of gfortran (and other compilers), and is also present in SGEEV

  • most likely these issues are due to the shift strategy for QZ

  • Confirmed by Rodney on Tue, 08 Feb 2011

bug0020 :: in xGESDD, workspace query can overflow for large matrices

  • CONFIRMED

  • reported by Stephan Ripke (Broad Institute, Boston) on Thu May 21 2009

  • confirmed by Julien Langou on Thu May 21 2009

  • see forum topic 1418

dead code* :: xLAHRD is now replaced by xLAHR2, xLAHRD is a dead code since LAPACK 3.1

  • xLAHRD will be removed at some point in the future from the distribution