topic Quote:OP wrote: Thanks mecej4 in Intel® oneAPI Math Kernel Library

Strangeness with DZGEMV

OP1 — Thu, 23 Apr 2020 19:57:54 GMT

The following code produces different outputs for DZGEMV and GEMV. The code is built with default 64-bit integer and real numbers; The parallel version of the MKL library is used (using ILP64 interfaces).

The path to the module files is: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.3.203\windows\mkl\include\intel64\ilp64

Using the link advisor, the libraries used are: mkl_blas95_ilp64.lib mkl_lapack95_ilp64.lib mkl_intel_ilp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib (library directory: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.3.203\windows\mkl\lib\intel64_win).

GEMV and MATMUL produce the expected result. I can't explain what DZGEMV does here.

This is on a WIN 10 machine, with Intel Parallel Studio XE 2019 Update 3 Cluster Edition.

PROGRAM P
USE BLAS95
IMPLICIT NONE

COMPLEX :: PHI(2,1),V(2),W(1),ALPHA,BETA
INTEGER :: M,N,ONE

PHI = CMPLX(1.0)
V   = CMPLX(2.0)
ALPHA = CMPLX(1.0)
BETA = CMPLX(0.0)
W = CMPLX(0.0)

M   = 2
N   = 1
ONE = 1

CALL DZGEMV('C',M,N,ALPHA,PHI,M,V,ONE,BETA,W,ONE)
WRITE(*,*) W

CALL GEMV(PHI,V,W,ALPHA=ALPHA,BETA=BETA,TRANS='C')
WRITE(*,*) W

W = MATMUL(CONJG(TRANSPOSE(PHI)),V)
WRITE(*,*) W

END PROGRAM P

Output:

 (2.00000000000000,0.000000000000000E+000)
 (4.00000000000000,0.000000000000000E+000)
 (4.00000000000000,0.000000000000000E+000)
Press any key to continue . . .

it looks like an issue. we

Gennady_F_Intel — Fri, 24 Apr 2020 04:19:47 GMT

it looks like an issue. we will check the problem on our side.

yes, I see the same output (0

Gennady_F_Intel — Fri, 24 Apr 2020 04:43:00 GMT

yes, I see the wrong output either but not exactly what you obtained.
(0.0000000E+00,0.0000000E+00)
(4.000000,0.0000000E+00)
(4.000000,0.0000000E+00)

the verbose mode shows that

Gennady_F_Intel — Fri, 24 Apr 2020 05:10:17 GMT

the verbose mode shows that different precisions have been called. dzgemm -- double complex, CSGEMV - single complex

MKL_VERBOSE Intel(R) MKL 2020.0 Update 1 Product build 20200208 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Win 2.60GHz cdecl intel_thread
MKL_VERBOSE DZGEMV(C,2,1,00000075776FFE10,00007FF7679CEB00,2,00007FF7679CEB10,1,00000075776FFE18,00007FF7679CEB20,1) 66.86us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:2
(0.0000000E+00,0.0000000E+00)
MKL_VERBOSE CGEMV(C,2,1,00000075776FFBD8,00007FF7679CEB00,2,00007FF7679CEB10,1,00000075776FFBE0,00007FF7679CEB20,1) 9.17us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:2
(4.000000,0.0000000E+00)
(4.000000,0.0000000E+00)

If I am not mistaken, OP is

mecej4 — Fri, 24 Apr 2020 11:43:12 GMT

If I am not mistaken, OP is passing an incorrect type argument to DZGEMV. The fifth argument, PHI, must be of type double precision real, not default complex or complex(8).

Thanks mecej4 - but shouldn't

OP1 — Fri, 24 Apr 2020 12:51:00 GMT

Thanks mecej4 - but shouldn't an interface argument inconsistency be detected by the compiler?

Quote:OP wrote: Thanks mecej4

mecej4 — Fri, 24 Apr 2020 14:13:00 GMT

OP wrote:
Thanks mecej4 - but shouldn't an interface argument inconsistency be detected by the compiler?

You have enabled the compiler to see an explicit interface to GEMV, which is a generic subprogram name, through the USE BLAS95 statement. The compiler will have checked the arguments in that call.

For the other BLAS routine that you call, DZGEMV, only an implicit interface is available to the compiler, and that one is incorrect. The compiler can detect such errors only if you provide an explicit and correct interface, or if there is more than one call from the same program unit to the same BLAS routine and the calls are mutually inconsistent.

Yes, I see. I just did a

OP1 — Fri, 24 Apr 2020 15:38:33 GMT

Yes, I see. I just did a rookie mistake here, ha ha. Thanks for the clarification!