updated on Tue Apr 19 2011
maintained by Julien Langou, U. Colorado Denver and Julie Langou, U. Tennessee
RED means BUG WAS CONFIRMED but IT IS STILL HERE
ORANGE means BUG WAS NOT CONFIRMED
GREEN means BUG WAS CORRECTED :

correction will be included in next release

bug fix available in LAPACK SVN repository
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 (MR), in which R is the smallest of P, MP, Q, and MQ.

An MbyM matrix is partitioned into a 2by2 block structure. The

dimensions of the blocks are PbyQ, Pby(MQ), (MP)byQ, and

(MP)by(MQ). 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

bug report sent by Paul Roberts on Oct 21st

reported to Zlatko Drmac and corrected by Zlatko Drmac
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"

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

bug report sent by Michael Chuvelev (Intel) on Tue 21 Jul 2009 to "lapack@cs.utk.edu". "Bug in LAPACK 3.2 dlarfb.f and likes"

see Michael Chuvelev and Julie’s emails, q.dat, tau.dat, and test_dorgql.f

confirmed by Rodney on Tue Feb 22 2011

corrected by Rodney on Thu March 3rd 2011
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 columnindex of the largest offdiagonal 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 quasitriangular * matrix S from the generalized Schur factorization; * 2by2 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) < 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 BLASlike routines). The notation A*H, A*T, A*N is used 549 times, The notation A^{T, A}N, A^H 19 times. (This is just for the Z routines.)

see Julien’s emails

vote on the lapackers mailing list: A*T (or A^{T) and A*H (or A}H): 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 nonreproducible 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 :: Noneigenvectors from DGEEV, problem in balancing

CONFIRMED

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

see forum topic 1818

see followup 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 :: Nonorthogonal eigenvectors returned from DSYEVR

CONFIRMED

bug report sent by Scipy team on April 22nd

Confirmed by Rodney on Tue, 17 Feb 2011

" I can reproduce similar problems that the user encountered with nonorthogonal 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

CONFIRMED

bug report sent by Cezary Sliwa (Instytut Fizyki PAN, Poland) on Thu 2 Jul 2009 to "lapack@cs.utk.edu".

see Cezary Sliwa’s test code, Cezary Sliwa’s matrix, and Cezary Sliwa’s email.

Confirmed by Rodney on Tue, 17 Feb 2011
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"

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