summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-02-18INTEGRATED CHANGES PROVIDED BY INTEL TEAM FOR LAPACKE -- SEE Eugene ↵julie2116-14258/+14275
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.
2014-02-14Correct a bug in the description of the WORK parameter in (c,z)la_syrpvgrw.fjulie2-2/+2
WORK is real Bug report sent from Elena Ivanova (Oracle) on Feb 14th 2014
2014-02-14Fix potential initiation issue in (c,d,s,z)lansy.fjulie4-36/+36
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.
2014-02-10( Let me know if I broke anything. I double checked. We should be fine but )langou10-113/+88
( 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
2014-02-09== Patch provided by Brad King from Kitware - brad.king@kitware.com ==julie7-10/+117
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.
2014-01-09Problem reported by zhaowei@sccas.cn on Jan 9th 2014julie2-2/+2
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...
2013-12-09Do not hide the CMAKE_GNUtoMS variable to users (Thanks Brad)julie1-1/+0
2013-12-07Fix typo in comment reported by elena.x.ivanova@oracle.com - zhetri2x fix ↵julie1-1/+1
was committed in r1465 (oops)
2013-12-07Fixed typos reported by elena.x.ivanova@oracle.com on Dec 5th julie2-4/+4
2013-12-06Remove unused leftover GNUtoMS support filejulie1-16/+0
2013-12-06Remove GNUtoMS code in favor of CMake builtin version - Thanks Brad (Kitware)julie7-125/+1
2013-12-06Require CMake >= 2.8.7 so we can use CMAKE_GNUtoMSjulie5-5/+5
2013-11-29fix to bug report 4331lawrence.mulholland2-8/+8
2013-11-27Split lines to make INtel Windows Compiler happy...julie2-2/+4
2013-11-26Correct bug reported by Alex Zotkevich from Intel langou2-96/+98
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
2013-11-25Apply patch from Nadezhda Mozartova from Intel. (Sent to Julien on Novemberlangou4-4/+4
20th.) Thanks Nadezhda! Thanks Intel!
2013-11-20 Fix info value problem for (c,d,s,z)tgsy2.f reported by Elena Ivanova ↵julie4-4/+4
(ORACLE) - Sent Nov 20th
2013-11-19Applying 2nd part of Mathieu's patch - modification in the include filejulie1-2/+2
2013-11-19Upadte version and datejulie12-36/+36
2013-11-19Apply patch submitted by Matthew Faverge, INRIA on Nov 19th 2013julie8-12/+15
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 );
2013-11-18LAPACK bug fix for XBLAS: bug revealed in testing of linear equation ↵igor17516-88/+704
routines, when XBLAS is linked
2013-11-17Update version and date on make.inc templatesjulie13-26/+26
2013-11-17fix Illegal grep pb in lapack_testingjulie1-1/+1
2013-11-17Slight modification to Lawrence patch for xTPQRT - Update conditions for ↵julie5-5/+5
testing parameter L - MIN(M,N) can be 0
2013-11-17update ilaverjulie2-8/+8
2013-11-17Update release number and datejulie173-529/+530
2013-11-17Patch provided by Lawrence Mulholland from Nag on Nov 1st 2013julie25-277/+629
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.
2013-10-15Typo in the comment on complex xHSEQR.langou2-2/+2
The formula: (QZ)*H*(QZ)**H. should read: (QZ)*T*(QZ)**H.
2013-10-05Added check for NaN in input parameter G to avoid infinite loop -- fixes bug110.james2-32/+16
2013-10-04FIX BUG 112.langou3-6/+6
(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
2013-10-04 Remove unused codejulie2-6/+0
2013-09-16Correct commentjulie1-2/+2
Problem reported by Elena Ivanova <Elena.x.Ivanova@Oracle.com> on Sept 16th "Both RES, and AYB have to be described as REAL."
2013-09-13Apply fix sent by Elena Ivanova (Oracle)julie4-18/+31
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
2013-09-13Add small fixes sent by Ake Sandgren <ake.sandgren@hpc2n.umu.se>julie9-3/+23
2013-09-12Fix "if test" semantic in xdrvpoxjulie4-8/+12
Bug report sent by Elena Ivanova <elena.x.ivanova@oracle.com> on Sept 10th
2013-08-21typo in previous fix: MIN(M,N)>0 NOT MIN(M,N)<0 when checking NB>MIN(M,N)lawrence.mulholland4-4/+4
2013-08-16Fix from Lawrence Mulholland (NAG). langou4-4/+4
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.
2013-07-22apply patch from Hong Xulangou4-4/+4
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
2013-07-20Add missing file in CMakeLists.txtjulie1-1/+1
2013-07-09Added LAPACK tests for 'rook' routines and drivers to LIN/Makefile ↵igor1752-20/+20
LIN/CMakeLists.txt
2013-07-09Modified test files for 'rook' pivoting LAPACK routines: LIN/cchkaa.f ↵igor17512-137/+385
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
2013-07-09Added 'rook' LAPACK routines and drivers to SRC/Makefile SRC/CMakeLists.txtigor1752-5/+13
2013-07-09Modified new 'rook' pivoting routines and drivers for Hermitian indefinite ↵igor1753-36/+42
matrices, Complex precision: zhetf2_rook.f zlahef_rook.f zhetri_rook.f
2013-07-09Modified new 'rook' pivoting routines and drivers for Hermitian indefinite ↵igor1753-24/+29
matrices, Complex precision: chetf2_rook.f clahef_rook.f chetri_rook.f
2013-07-04modified error hadling routines for LIN testing of new Hermitian 'rook' ↵igor1751-3/+1
pivoting code: aladhd.f
2013-07-04modified error hadling routines for LIN testing of new Hermitian 'rook' ↵igor1752-45/+32
pivoting code: aladhd.f, alahd.f
2013-06-27bug fix provided by Elena Ivanova via email.james4-4/+4
2013-06-27updated xlarfb routinesjames4-662/+493
2013-06-05fixed array index problems in new CSD routines by adding MAX() to ensure ↵james8-36/+36
index is at least 1 -- this fixes array bounds violations in the test suite when array bounds checking is enabled
2013-05-16Now using 2-norm to compute vector norms of row and column for balancing ↵james4-44/+21
algorithm. This seems to fix problems with balancing causing very large backward error for certain Hessenberg matrices, including the often cited example of Watkins.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 23:14:05 +0000