summaryrefslogtreecommitdiff
path: root/SRC/sorbdb2.f
diff options
context:
space:
mode:
authorjulie <julielangou@users.noreply.github.com>2016-01-19 04:37:26 +0000
committerjulie <julielangou@users.noreply.github.com>2016-01-19 04:37:26 +0000
commit50dacaf659e6894dd5adbcfa379cce7352e9baf2 (patch)
tree85f6475ac2a913a18ba177367e088eb8d9b72899 /SRC/sorbdb2.f
parent43e85a37b9b765a6473df7c1334888d21a796d45 (diff)
downloadlapack-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/sorbdb2.f')
-rw-r--r--SRC/sorbdb2.f4
1 files changed, 2 insertions, 2 deletions
diff --git a/SRC/sorbdb2.f b/SRC/sorbdb2.f
index 582540e3..4c047a37 100644
--- a/SRC/sorbdb2.f
+++ b/SRC/sorbdb2.f
@@ -291,8 +291,8 @@
$ X11(I+1,I), LDX11, WORK(ILARF) )
CALL SLARF( 'R', M-P-I+1, Q-I+1, X11(I,I), LDX11, TAUQ1(I),
$ X21(I,I), LDX21, WORK(ILARF) )
- S = SQRT( SNRM2( P-I, X11(I+1,I), 1, X11(I+1,I),
- $ 1 )**2 + SNRM2( M-P-I+1, X21(I,I), 1, X21(I,I), 1 )**2 )
+ S = SQRT( SNRM2( P-I, X11(I+1,I), 1 )**2
+ $ + SNRM2( M-P-I+1, X21(I,I), 1 )**2 )
THETA(I) = ATAN2( S, C )
*
CALL SORBDB5( P-I, M-P-I+1, Q-I, X11(I+1,I), 1, X21(I,I), 1,