Bug in comments on array size reported by a Sergey Kuznetsov from Intel.

The size of array RWORK in {c,z}dbsqr was given incorrectly.

Previous version for cbdsqr.f read
          RWORK is REAL array, dimension (2*N)
          if NCVT = NRU = NCC = 0, (max(1, 4*N-4)) otherwise

Now reads
          RWORK is REAL array, dimension (4*N)

bug found by Themos Tsikas fron NAG Ltd

LAPACK FORUM topic #4558

Hello

In zlanhf.f, first executable statements
Code: Select all
      IF( N.EQ.0 ) THEN
         ZLANHF = ZERO
         RETURN
      ELSE IF( N.EQ.1 ) THEN
         ZLANHF = ABS(A(0))
         RETURN
      END IF

When N=1, we should be ignoring any imaginary part (as we do for general diagonal elements later on) and so it should read
Code: Select all
      IF( N.EQ.0 ) THEN
         ZLANHF = ZERO
         RETURN
      ELSE IF( N.EQ.1 ) THEN
         ZLANHF = ABS(DBLE(A(0)))
         RETURN
      END IF

Themos Tsikas
NAG Ltd

Applied patch provided from vitaut on LAPACK forum on June 13th.
The patch fixes the warnings (Policy CMP0026) by replacing the deprecated LOCATION target
property with the generator expression $<TARGET_FILE>

See http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=13&t=4556&p=10939#p10939

Update version number in CMAKE - Thanks Allan Wollaber for the bug report (April 15th 2014)

Update version number in CMAKE - Thanks Allan Wollaber for the bug report (April 15th 2014)

Adding missing routine in repository

Corrected minor bug submitted by Elena Ivanova, Oracle on March 18th 2014.

From Elena:
there is a minor bug in /LIN/dchkql.f:
Array IWORK  (a parameter of this routine) is not used at all.
It would be better to remove IWORK from the list of parameters,
remove its declaration and description in the code of /LIN/dchkql.f:

Note: only dchkql had that IWORK parameter, [c,s,z]chkql don't have it.

Fix typos found by Jeremy Du Croz

INTEGRATED CHANGES PROVIDED BY INTEL TEAM FOR LAPACKE -- SEE Eugene Chereshnev email on Feb 18th
 --> THANK YO INTEL <--

We performed auto-replacement matrix_order -> matrix_layout in the LAPACKE C Interface.
Also we applied several bug fixes which were presented on our side and added two LAPACKE interfaces for
function LAPACK_stpqrt which weren't represented on your side (although interfaces for d/c/z/pqrt were).

All changes are reflected in the archive in attachment (only modified files in the archive). All changes were performed for revision 1471.

Summary of changes:
1.  Files:
    lapacke_stprfb.c
    lapacke_dtprfb.c
    lapacke_ctprfb.c
    lapacke_ztprfb.c

    lapacke_stprfb_work.c
    lapacke_dtprfb_work.c
    lapacke_ctprfb_work.c
    lapacke_ztprfb_work.c
    lapacke.h

    Expression MAX(1,ldwork)*MAX(n,k) was replaced by 'work_size'. It's not a bug but apparently 'work_size' is right expression in this place.
    Also in functions lapacke_(c/z)tprfb type of 'work' array was changed from float/double to
    lapack_complex_float/lapack_complex_double. Array 'work' is passed to lapacke_(c/z)tprfb_work and it calls
    LAPACK_(c/z)tprfb (and passes array 'work') but LAPACK_(c/z)tprfb has argument 'work' of complex type:
    SRC/ctprfb.f:
    *>          WORK is COMPLEX array, dimension
    *>          (LDWORK,N) if SIDE = 'L',
    *>          (LDWORK,K) if SIDE = 'R'.
    and SRC/ztprfb.f:
    *>          WORK is COMPLEX*16 array, dimension
    *>          (LDWORK,N) if SIDE = 'L',
    *>          (LDWORK,K) if SIDE = 'R'.
    Types of 'work' array in lapacke.h for LAPACK_(c/z)tprfb are float/double so they aren't correct.
    The archive includes changes in lapacke.h and source files:
        types of 'work' array in LAPACK_(c/z)tprfb: float/double -> lapack_complex_float/lapack_complex_double
        types of 'work' array in LAPACKE_(c/z)tprfb_work: float/double -> lapack_complex_float/lapack_complex_double
        In a similar way types of allocated 'work' arrays in LAPACKE_(c/z)tprfb were replaced.
    Also you can see here why MAX(1,ldwork)*MAX(n,k) isn't fully correct expression for work_size.

2.  Files:
    lapacke_cuncsd.c
    lapacke_dorcsd.c
    lapacke_sorcsd.c
    lapacke_zuncsd.c

    From documentation of LAPACK_cuncsd (for other three LAPACK functions IWORK must have same size):
    *>          IWORK is INTEGER array, dimension (M-MIN(P,M-P,Q,M-Q))

   So it's not correct here to allocate working array with MAX(1,m-q) size.
   Changes:
    lapack_int r;
    r=MIN(p,m-p);
    r=MIN(r,q);
    r=MIN(r,m-q);
    MAX(1,m-q) -> MAX(1,m-r)

3.  Files:
    lapacke_cgbsvxx_work.c
    lapacke_cgesvxx_work.c
    lapacke_chesvxx_work.c
    lapacke_cposvxx_work.c
    lapacke_csysvxx_work.c
    lapacke_dgbsvxx_work.c
    lapacke_dgesvxx_work.c
    lapacke_dposvxx_work.c
    lapacke_dsysvxx_work.c
    lapacke_sgbsvxx_work.c
    lapacke_sgesvxx_work.c
    lapacke_sposvxx_work.c
    lapacke_ssysvxx_work.c
    lapacke_zgbsvxx_work.c
    lapacke_zgesvxx_work.c
    lapacke_zhesvxx_work.c
    lapacke_zposvxx_work.c
    lapacke_zsysvxx_work.c

    Functions doesn't perform right transposition for 'err_bnds_norm' and 'err_bnds_comp' matrices:
    From documentation of these functions:
    *>          ERR_BNDS_NORM is (SINGLE/DOUBLE) PRECISION array, dimension (NRHS, N_ERR_BNDS)
    *>          ERR_BNDS_COMP is (SINGLE/DOUBLE) PRECISION array, dimension (NRHS, N_ERR_BNDS)
    So for interface functions right 'lda' for 'err_bnds_norm' and 'err_bnds_comp' matrices is 'n_err_bnds' rather than 'nhrs' in the case of LAPACK_ROW_MAJOR.

4.  Files:
    lapacke_stpqrt.c
    lapacke_stpqrt_work.c
    lapacke/src/Makefile
    lapacke/src/CMakeLists.txt

    Interfaces for LAPACK_spqrt were added: lapacke_stpqrt.c and lapacke_stpqrt_work.c and appropriate changes were performed in Makefile and CMakeLists.txt.
    Declaration of LAPACK_spqrt was added to lapacke.h.

Correct a bug in the description of the WORK parameter in (c,z)la_syrpvgrw.f
WORK is real
Bug report sent from Elena Ivanova (Oracle) on Feb 14th 2014

Fix potential initiation issue in (c,d,s,z)lansy.f
Bug report sent from Elena Ivanova on Feb 2014

Array WORK is initialized with ZERO when 'L' and is not initialized when 'U'.
There can be some garbage in WORK. Move up the initialization of WORK before the line
   IF( LSAME( UPLO, 'U' ) ) THEN.

Rearrange loop ordering numbers.

( Let me know if I broke anything. I double checked. We should be fine but )
( please let me know if concerns/problems.                                 )

1) The comments in ICMAX1 (resp. IZMAX1) were not correct. The comments read:
"ICMAX1 finds the index of the element whose real part has maximum absolute
value." It should have read: "ICMAX1 finds the index of the first vector
element of maximum absolute value." This is corrected. The problem was reported
Eloy Romero Alcalde from the SLEPc team, Universitat Politècnica de València
and confirmed by Nick Higham, Sven Hammarling and Julien Langou.

2) The routine ICAMAX (resp. IZAMAX) from the BLAS evolved without ICMAX1
(resp. IZMAX1). Reconcialated both version. So essentially took the ICAMAX
currently in the BLAS and changed it appropriately for an ICMAX1.

3) Remove the use of statement function in ICMAX1 (resp. IZMAX1). Now obsolete
in FORTRAN.

4) Change comments in BLAS routines: SCABS1, DCABS1, ICAMAX, IZAMAX, SCASUM,
and DZASUM. Remove the use of "absolute value of a complex number" for the
quantity "| Re(.) | + | Im(.) |". For example:
before
   DCABS1 computes absolute value of a double complex number
after
   DCABS1 computes |Re(.)| + |Im(.)| of a double complex number

== Patch provided by Brad King from Kitware - brad.king@kitware.com ==

Provide CMake packages for both LAPACK and LAPACKE

Teach "lapack-config.cmake" to provide variables

 LAPACK_blas_LIBRARIES
 LAPACK_lapack_LIBRARIES

that contain either the target names when using the reference
implementation or the system libraries found for them.

Configure a "lapacke-config.cmake" file for the build and install
trees to package LAPACKE.  Teach it to load the LAPACK package
installed with it.  Provide variables

 LAPACKE_INCLUDE_DIRS
 LAPACKE_LIBRARIES

containing the header file search path for lapacke headers
and the list of lapacke library targets.

This requires CMake 2.8.10 to separate the installation export
for the lapacke library from the other targets.

Problem reported by zhaowei@sccas.cn on Jan 9th 2014

Corrected comments to list Z as input/output

> Email
i just found a mistake in the comments of 'dlasq3.c' while reading the code:

/*  Z      (input) DOUBLE PRECISION array, dimension ( 4*N ) */
/*         Z holds the qd array. */

but Z can be changed in that subroutine...i just think '(output)' should be added to avoid misleading user...

Do not hide the CMAKE_GNUtoMS variable to users (Thanks Brad)

Fix typo in comment reported by elena.x.ivanova@oracle.com - zhetri2x fix was committed in r1465 (oops)

Fixed typos reported by elena.x.ivanova@oracle.com on Dec 5th

Remove unused leftover GNUtoMS support file

Remove GNUtoMS code in favor of CMake builtin version - Thanks Brad (Kitware)

Require CMake >= 2.8.7 so we can use CMAKE_GNUtoMS

fix to bug report 4331

Split lines to make INtel Windows Compiler happy...

Correct bug reported by Alex Zotkevich from Intel
See: http://icl.utk.edu/lapack-forum/viewtopic.php?f=13&t=4392

Bug: During workspace computation, LAPACK code CGESVD was calling other
subroutines (e.g. CGEQRF) with REAL DUM variable as COMPLEX WORK variable.  DUM
(in CGESVD) is REAL while WORK (in called subroutines) is COMPLEX.  This
corrupts the stack when a value is set in WORK.

Fix: In CGESVD, use the COMPLEX CDUM variable (already present in the code)
instead of the REAL DUM variable.  Since I was at it, the COMPLEX "TAU"
variables (not referenced anyway) were passed the REAL DUM variable, I changed
the code so that the COMPLEX CDUM variable is passed. This is cleaner like
this.

Same problem with ZGESVD. Same fix.

Alex's post:
Hi, We recently found a stack corruption issue in (C,Z)GESVD that potentially
could even lead to incorrect xerbla error message.  In ZGESVD array DUM which
is used in LWORK query is a double precision array of size 1 allocated on
stack:
DOUBLE PRECISION DUM( 1 )
DUM comes to ( ZGEQRF, ZUNGQR, ... ) as a WORK array to return an optimal LWORK
value.  But in ( ZGEQRF, ZUNGQR, ... ) array WORK is declared as a COMPLEX*16
array. So WORK(1) = 1 corrupts the stack as it deals with complex value while
pointer on input of the function is a pointer to double: (oooooooo|xxxxxxxx),
oooooooo fills with LWORK value, xxxxxxxx corrupts. Let compiler use xxxxxxxx
to hold some value. After LWORK query the value will turn to be a zero.  "Hacky
fix" would be to allocate DUM array of size 2.
W.B.R.
Alex Zotkevich

Apply patch from Nadezhda Mozartova from Intel. (Sent to Julien on November
20th.) Thanks Nadezhda! Thanks Intel!

 Fix info value problem for (c,d,s,z)tgsy2.f reported by Elena Ivanova (ORACLE) - Sent Nov 20th

Applying 2nd part of Mathieu's patch - modification in the include file

Upadte version and date

Apply patch submitted by Matthew Faverge, INRIA on Nov 19th 2013

There are problems  in LAPACKE complex lacn2 interfaces. Those functions don't have a "isgn" parmeter in LAPACK. This exists only for real interface. The problem is present in the four files of C and Z functions.

In Lapack:
  SUBROUTINE ZLACN2( N, V, X, EST, KASE, ISAVE )

In Lapacke:
   LAPACK_zlacn2( &n, v, x, isgn, est, kase, isave );

LAPACK  bug fix for XBLAS: bug revealed in testing of linear equation routines, when XBLAS is linked

Update version and date on make.inc templates

fix Illegal grep pb in lapack_testing

Slight modification to Lawrence patch for xTPQRT - Update conditions for testing parameter L - MIN(M,N) can be 0

update ilaver

Update release number and date

Patch provided by Lawrence Mulholland from Nag on Nov 1st 2013

Email below:
============
I have been incorporating some routines into the NAG Library,
which means some automatic code translation and writing some
example and test programs.

The routines I have been adding are:
?geqrt, ?gemqrt, ?tpqrt, ?tpmqrt, ?orcsd, ?uncsd

At the end of this message I will give you my current svn status
and svn diff for consideration and approval before I commit.

In each case, when testing immediate exits, my tests failed because
constraints were mutually exclusive for the immediate return case.
I have already committed changes to the constraints for some of
the above to allow immediate exit.
I have completed this for the remainder of this set.

Less importantly, there are things in the code that trip up a checking
compiler:
  a) an
           IF ( clause1(i) .AND. clause2(array(i)) ) THEN

      where array(i) is either not initialized or is out of bounds if
      clause1(i) is .FALSE.

      This is wrong since a Fortran compiler is at liberty to test clause2 first.
      In my changes this has been split into two as best suits the case.

 b) an
          CALL SUB (i, array(N-i+2))
     with i = 1 and array(N+1) either not initialized or out of bounds, but
     internally array(N+1) is not referenced.

     In this case I don't think the Fortran standard is clear, but it trips up the
     nagfor compiler with checking on. So in the NAG incorporated versions
     of Lapack routines such calls are protected and/or
     a special i=1 call is made.
     The changes I want to commit also do this.

 c) workspace queries passing zero instead of array references
         e.g.
                lwork = -1
                call barf(n,m,0,0,0,0,0,-1,info)

     a checking compiler won't like this.
     I have changed cases like this to pass available arrays of sufficient size
     and the right shape in place of the zeros.

Typo in the comment on complex xHSEQR.
The formula:
(QZ)*H*(QZ)**H.
should read:
(QZ)*T*(QZ)**H.

Added check for NaN in input parameter G to avoid infinite loop -- fixes bug110.

FIX BUG 112.

    (Bug reported on Aug 18 2013 by Daniel Strobusch on LAPACK mailing list)
    (Bug fixed by Rodney on Aug 19 2013)

This is a problem with gfortran.  One need to force gfortran to allocate all
local arrays on the stack.  One way to do this is to have the option
-frecursive

 Remove unused code

Correct comment
Problem reported by Elena Ivanova <Elena.x.Ivanova@Oracle.com> on Sept 16th
"Both RES, and AYB have to be described as REAL."

Apply fix sent by Elena Ivanova (Oracle)

There is FPE in the 457th line of CDRVRFP:
cdrvrfp.f
(dbx) where
=>[1] cdrvrfp(nout = 6, nn = 9, nval = ARRAY, nns = 3, nsval = ARRAY, nnt = 9, ntval = ARRAY, thresh = 30.0, a = ARRAY, asav = ARRAY, afac = ARRAY, ainv = ARRAY, b = ARRAY, bsav = ARRAY, xact = ARRAY, x = ARRAY, arf = ARRAY, arfinv = ARRAY, c_work_clatms = ARRAY, c_work_cpot02 = ARRAY, c_work_cpot03 = ARRAY, s_work_clatms = ARRAY, s_work_clanhe = ARRAY, s_work_cpot01 = ARRAY, s_work_cpot02 = ARRAY, s_work_cpot03 = ARRAY), line 457 in "cdrvrfp.f"

MAIN(), line 244 in "cchkrfp.f"
When N=0, attempt to calculate a condition number → FPE, because we try to delete by zero (ANORM = 0.0, AINVNM = 0.0) in the 457th line:
Line 457:
      RCONDC = ( ONE / ANORM ) / AINVNM

Add small fixes sent by Ake Sandgren <ake.sandgren@hpc2n.umu.se>

Fix "if test" semantic in xdrvpox
Bug report sent by Elena Ivanova <elena.x.ivanova@oracle.com> on Sept 10th

typo in previous fix: MIN(M,N)>0 NOT MIN(M,N)<0 when checking NB>MIN(M,N)

Fix from Lawrence Mulholland (NAG).

From Lawrence:
The *GEQRT routines are supposed to return immediately when N=0 or M=0.
However the code is such that an INFO = -3 is triggered since we are
trying to satisfy
ELSE IF( NB.LT.1 .OR. NB.GT.MIN(M,N) )THEN
INFO = -3
should be
ELSE IF( NB.LT.1 .OR. ( NB.GT.MIN(M,N) .AND. MIN(M,N).LT.0 ) )THEN
INFO = -3

Also on a side note, I think we could allow NB to be greater than MIN(M,N) in
the interface and then reset NB as needed if the user's NB is too large.
Another day. Good enough for now.

Julien.

apply patch from Hong Xu

patch sent to lapack mailing list on Sunday July 21st

In the input parameter checking, LDZ was not checked correctly
LDZ was checked against M instead of N essentially

Add missing file in CMakeLists.txt

Added LAPACK tests for 'rook' routines and drivers to LIN/Makefile LIN/CMakeLists.txt

Modified test files for 'rook' pivoting LAPACK routines: LIN/cchkaa.f LIN/cchkhe_rook.f LIN/cdrvhe_rook.f LIN/cerrhe.f LIN/cerrvx.f LIN/zchkaa.f LIN/zchkhe_rook.f LIN/zdrvhe_rook.f LIN/zerrhe.f LIN/zerrvx.f ctest.in ztest.in

Added 'rook' LAPACK  routines and drivers to SRC/Makefile SRC/CMakeLists.txt

Modified new 'rook' pivoting routines and drivers for Hermitian indefinite matrices, Complex precision: zhetf2_rook.f zlahef_rook.f zhetri_rook.f

Modified new 'rook' pivoting routines and drivers for Hermitian indefinite matrices, Complex precision: chetf2_rook.f clahef_rook.f chetri_rook.f

modified error hadling routines for LIN testing of new Hermitian 'rook' pivoting code: aladhd.f

modified error hadling routines for LIN testing of new Hermitian 'rook' pivoting code: aladhd.f, alahd.f

bug fix provided by Elena Ivanova via email.

updated xlarfb routines

fixed array index problems in new CSD routines by adding MAX() to ensure index is at least 1 -- this fixes array bounds violations in the test suite when array bounds checking is enabled

Now using 2-norm to compute vector norms of row and column for balancing algorithm.
This seems to fix problems with balancing causing very large backward error for certain
Hessenberg matrices, including the often cited example of Watkins.

fixed comments in (c,z)errsy.f

changed comments in (c,z)hetf2.f

added LAPACK routine (c,z)hesv_rook.f

added LAPACK routine (c,z)hecon_rook.f

added LAPACK routine (c,z)hetri_rook.f

added LAPACK routine (c,z)hetrs_rook.f

added LAPACK routine (c,z)hetrf_rook.f

added LAPACK routines (c,z)hetf2_rook.f

fixed comments in LAPACK routines (c,z)lahef.f and (c,z)lahef_rook.f

fixed comments in LAPACK routines (c,z)lahef.f and (c,z)lahef_rook.f

Fixed comments in (c,z)lahef.f and (c,z)lahef_rook.f

added HR (Hermitian 'rook') path to LAPACK test routines alaerh.f alahd.f aladhd.f

changed comments in LAPACK testing routine (c,z)latb4.f

fixed comments in LAPACK testing routines (s,d,c,z)lavsy.f, (s,d,c,z)lavsy_rook.f (c,z)lavhe.f, (c,z)lavhe_rook.f

fixed comments in LAPACK test routines (s,d,c,z)syt01.f, (s,d,c,z)syt01_rook.f  and (c,z)het01.f, (c,z)het01_rook.f

minor changes in LAPACK testing routines (s,d,c,z)drvsy.f, (s,d,c,z)drvsy_rook.f, (c,z)drvhe.f, and (c,z)drvhe_rook.f

removed whitespace in LAPACK testing routines (s,d,c,z)chksy.f and (s,d,c,z)chksy_rook.f and (c,z)chkhe.f (c,z)chkhe_rook.fand minor modifications

changed comments in LAPACK testing routines (s,d,c,z)chksy.f and (s,d,c,z)chksy_rook.f (c,z)chkhe.f (c,z)chkhe_rook.fand minor modifications

changed comments in LAPACK testing routines (c,z)chksy.f and (c,z)chksy_rook.f (c,z)chkhe.f (c,z)chkhe_rook.f and minor modifications

changed comments in LAPACK testing routines (c,z)chksy.f and (c,z)chksy_rook.f (c,z)chkhe.f (c,z)chkhe_rook.f and minor modifications

changed comments in LAPACK testing routines (c,z)chksy.f and (c,z)chksy.f

changed coments in LAPACK testing routines (c,z)chksy.f and (c,z)chksy.f

added test routines (c,z)chkhe_rook.f  and (c,z)drvhe_rook.f  for Hermitian factorization routines with rook pivoting algorithm

added test routines (c,z)chkhe_rook.f  and (c,z)drvhe_rook.f  for Hermitian factorization routines with rook pivoting algorithm

 lapacke.h: template with C linkage error - forum topic 4221

removed references to example_ZGESV_rowmajor.c

removed example_ZGESV_rowmajor.c

corrected bug found by Tyrone Rees posted on email list:

"I think there's a bug in the routine dlaqp2.f in version 3.4.2 of LAPACK
(and possibly earlier). Line 220 of the source is
   IF( I.LE.N ) THEN
whereas for the other versions the same line reads
   IF( I.LT.N ) THEN

This difference appears to make the routine dgeqp3 fall over when asked
to do a factorization of the last two columns of a 10x5 matrix.  The NAG
fortran compiler gives the error:
 Subscript out of range for assumed-size array A - Access to element 22
but actual argument has only 20 elements
 Program terminated by fatal error

The single precision version runs without a hiccup.

Best wishes,

Tyrone"

Applied patch provided by Sergey Kuznetsov @ Intel, fixes bug where TAU2 can be uninitialized.

added code to set the last pivots to n: ipiv(n)=jpiv(n)=n

Update and add examples

Remove unused file

Fix typos in README

Add c/zlacp2 for PLASMA team

Updated comments in (s,d,c,z)lasy_rook.f and (c,z)lahe_rook.f

updated comments in (s,d,c,z)lasyf.f and  (c,z)lahef.f

Updated comments in (s,d,c,z)sytf2_rook.f

Updated comments in  (s,d,c,z)sytf2.f and (c,z)hetf2.f

updated comments in

fixed comments in clahef_rook.f and zlahef_rook.f

Commit Victor Liu's suggestion about making the complex division routine more robust
tests and builds seems fine.

Message sent on Oct 18th
I just saw a paper on ArXiv about making the complex division routine more robust:
http://arxiv.org/abs/1210.4539
Second author is actually the original inventor of the current algorithm in Lapack.
I have attached my modified DLADIV routine, which passes all the tests in the build process.

Replaced IF(J.LE.N) by IF(J.LT.N) for 'U', where U12 is put in standard form by partially undoing the interchanges, also added comments to the part where U21 is put in standard form; Similarly, replaced IF(J.GE.1) by IF(J.GT.1) for 'L', where L21 is put in standard form by partially undoing the interchanges, also added comments to the part where L21 is put in standard form; Affected files: zlahef.f clahef.f zlasyf.f clasyf.f dlasyf.f slasyf.f