naresh-kamboju/lapack.git - [no description]

Age	Commit message (Collapse)	Author
2016-12-23	Updating version number on source file modified since 3.6.1	Julie
	This is really old school, but a lot of times we have users sending us copy pasting of codes, and that is the only way to know the version of the code.
2016-07-09	STYLE: Remove trailing whitespace in Fortran files	Hans Johnson
	This is mostly a long term maintenance improvement. Many coding styles require elimination of trailing whitespace, and many editors and source code management configurations automatically gobble up whitespace. When these tools gobble up whitespace, it complicates reviewing the meaningful code changes. By removing whitespace on one patch, it makes future code reviews much easier. =SCRIPT==================================================================== if which tempfile &>/dev/null; then TEMPMAKER=tempfile elif which mktemp &>/dev/null; then TEMPMAKER=mktemp else echo "Cannot find tempfile program." 2>&1 exit 1 fi MYTEMP=$($TEMPMAKER) trap 'rm -f $MYTEMP' SIGINT SIGTERM stripit() { echo "stripping $1" sed 's/[ \t]*$//' "$1" > $MYTEMP cp $MYTEMP "$1" } if [ $# -gt 0 ]; then while [ "$1" != "" ]; do stripit $1 shift done else while read -t 2; do stripit $REPLY done fi rm $MYTEMP =================================================
2016-06-18	Update date, version for 3.6.1 release	Julie

2016-01-19	Oops..Missing ending bracket in last commit..	julie

2016-01-19	Commit interface inconsistencies fix proposed by David Vowles on Jan 18th ↵	julie
	2016 - sent directly to Julie Confirmed by Julie on Jan 18th 2016 Routines: [cz]unbdb[1234].f, [SD]ORBDB[1234].f == First Email from David == I have encountered some additional errors when compiling Lapack v3.6.0 with Compaq Visual Fortran. Interestingly, these errors did not occur when compiling with Intel Visual Fortran. File: “SRC\cunbdb1.f” Lines: 310-312 C = SQRT( SCNRM2( P-I, X11(I+1,I+1), 1, X11(I+1,I+1), $ 1 )2 + SCNRM2( M-P-I, X21(I+1,I+1), 1, X21(I+1,I+1), $ 1 )2 ) The interface to the BLAS SCNRM2 function is SCNRM2(N,X,INCR) whereas the interfaces to the SCNRM2 function calls in “SRC\cunbdb1.f” are of the form SCNRM2(N, X1, INC1, X2, INC2). Similar interface inconsistencies are found in the following files: File: “SRC\cunbdb2.f” Lines: 299-300 File: “SRC\cunbdb3.f” Lines: 299-300 File: “SRC\cunbdb4.f” Lines: 347-349 The above inconsistencies between the interface of the function definition and the function call causes compilation failure of the test-function “xeigtstc.exe” It is unclear if function calls of the form SCNRM2(N, X1, INC1, X2, INC2) should be replaced by SCNRM2(N, X1, INC1) or if some other correction is required. == Second Email from David: == By the way, I found similar interface inconsistencies in the SRC\cunbdb<n>.f subroutines for <n> = 1 to 4; and in the SRC\<t>ORBDB<n>.f subroutines for <t> = D and S and <n> = 1 to 4. A total of 16 subroutines are affected – the four mentioned in my previous email and the twelve mentioned here. After changing the calls in the affected files from NRM2(N,X1,INC1,X2,INC2) to NRM2(N,X1,INC1) my build for Windows x86 with Compaq Visual Fortran (CVF) completed successfully and all tests passed. But I do await your verdict as to whether the proposed modification to the function calls is correct. If I understand correctly STDCALL is the default calling mechanism for the CVF compiler whereas for the (Intel Visual Fortran) IVF compiler it is the C calling convention. I wonder if this difference in calling convention explains why the affected test programs compile and link with IVF but fail to link with CVF.
2012-07-27	Commit Brian Sutton new CS Decomposition routines.	julie
	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.