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.
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
=================================================
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.
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.
Mark Gates