diff options
| author | julie <julielangou@users.noreply.github.com> | 2016-01-19 04:37:26 +0000 |
|---|---|---|
| committer | julie <julielangou@users.noreply.github.com> | 2016-01-19 04:37:26 +0000 |
| commit | 50dacaf659e6894dd5adbcfa379cce7352e9baf2 (patch) | |
| tree | 85f6475ac2a913a18ba177367e088eb8d9b72899 /SRC/sorbdb3.f | |
| parent | 43e85a37b9b765a6473df7c1334888d21a796d45 (diff) | |
| download | lapack-50dacaf659e6894dd5adbcfa379cce7352e9baf2.tar.gz lapack-50dacaf659e6894dd5adbcfa379cce7352e9baf2.tar.bz2 lapack-50dacaf659e6894dd5adbcfa379cce7352e9baf2.zip | |
Commit interface inconsistencies fix proposed by David Vowles on Jan 18th 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.
Diffstat (limited to 'SRC/sorbdb3.f')
| -rw-r--r-- | SRC/sorbdb3.f | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/SRC/sorbdb3.f b/SRC/sorbdb3.f index ea52f4db..74ea60f6 100644 --- a/SRC/sorbdb3.f +++ b/SRC/sorbdb3.f @@ -293,8 +293,8 @@ $ X11(I,I), LDX11, WORK(ILARF) ) CALL SLARF( 'R', M-P-I, Q-I+1, X21(I,I), LDX21, TAUQ1(I), $ X21(I+1,I), LDX21, WORK(ILARF) ) - C = SQRT( SNRM2( P-I+1, X11(I,I), 1, X11(I,I), - $ 1 )**2 + SNRM2( M-P-I, X21(I+1,I), 1, X21(I+1,I), 1 )**2 ) + C = SQRT( SNRM2( P-I+1, X11(I,I), 1 )**2 + $ + SNRM2( M-P-I, X21(I+1,I), 1 )**2 ) THETA(I) = ATAN2( S, C ) * CALL SORBDB5( P-I+1, M-P-I, Q-I, X11(I,I), 1, X21(I+1,I), 1, |