Missing variables in stdcall headers?

[Mikhail_K_]

Hi,

I have MKL 2017 with update 1 installed in Windows 10.

I'm using DORM22 from Lapack as an example.

cdecl headers:

void DORM22( const char* side, const char* trans, const MKL_INT* m, const MKL_INT* n,
             const MKL_INT* n1, const MKL_INT* n2, const double* q, const MKL_INT* ldq,
             double* c, const MKL_INT* ldc, double* work, const MKL_INT* lwork,
             MKL_INT* info );

stdcall:

void __stdcall DORM22( const char* side, int side_len, const char* trans, int trans_len,
                       const MKL_INT* n1, const MKL_INT* n2, const double* q, const MKL_INT* ldq,
                       double* c, const MKL_INT* ldc, double* work, const MKL_INT* lwork,
                       MKL_INT* info );

13 variables each. But is it me or n and m are missing from the stdcall declaration? In mkl_intel_s.lib I find 

_DORM22@60

So it should be 15 variables...

Same story with

_CHLA_TRANSTYPE@4

_CUNCSD2BY1@92

_DORCSD2BY1@84

_DORM22@52

_MKLFREETLS@4

_MKL_CTPPACK@44

_MKL_CTPUNPACK@44

_MKL_DTPPACK@44

_MKL_DTPUNPACK@44

_MKL_STPPACK@44

_MKL_STPUNPACK@44

_MKL_ZTPPACK@44

_MKL_ZTPUNPACK@44

_SORCSD2BY1@84

_SORM22@52

_VSLGETNUMREGBRNGS@4

_ZUNCSD2BY1@92

Regards,

MK

[mecej4]

The arguments side and trans are, in effect, single-character strings since only the first character of each is used. Therefore, if string lengths are passed as "hidden" arguments at the end, after all the other variables, they can be left out or, if present, ignored. The caller will push those lengths first on the stack, but the Lapack/MKL routine knows that only the first character is needed, so it does not obtain the lengths that have been placed on the stack.

On the other hand, when the string length is passed immediately after each string, as in Compaq/Digital Fortran, the caller puts those lengths on the stack, so the C declaration has to show a place-holder variable in the corresponding position.

[Mikhail_K_]

Hi, yep, but then __stdcall DORM22 should have 15 variables, not 13.

My question was: where are matrix dimensions

const MKL_INT* m, const MKL_INT* n

in the stdcall declaration (windows\mkl\include\mkl_lapack_stdcall.h)?

[Mikhail_K_]

Is this going to be fixed?

Missing const MKL_INT* m, const MKL_INT* n,

in mkl_lapack_stdcall.h for DORM22

[SergeyKostrov]

>>...The arguments side and trans are, in effect, single-character strings since only the first character of each >>is used. Therefore, if string lengths are passed as "hidden" arguments at the end, after all the other variables, they >>can be left out or, if present, ignored. This is not correct for C or C++ since these two arguments declared at the beginning ( ! ) of declaration of all arguments. If these two arguments would be declared as ... void DORM22( .., .., < skipped > .., .., const char* side = NULL, const char* trans = NULL ) ... that is at the end, then your statement would be correct.

[mecej4]

Lapack is written in Fortran. As you can see at http://www.netlib.org/lapack/explore-html/d3/db9/group__complex_o_t_h_e_rcomputational_gae585aa301066e2bcfd1fad4a93e2e6df.html#gae585aa301066e2bcfd1fad4a93e2e6df , DORM22 has 13 arguments, two of which are single-character arguments. If someone wants to call Lapack from C, the C code has to obey the argument passing conventions of the Fortran compiler used to build Lapack. For this reason, the C headers of Lapack routines will have to be modified if a different Fortran compiler or a different Fortran calling convention is used!

[SergeyKostrov]

>>...But is it me or n and m are missing from the stdcall declaration? ... void __stdcall DORM22( const char* side, int side_len, const char* trans, int trans_len, const MKL_INT* n1, const MKL_INT* n2, const double* q, const MKL_INT* ldq, double* c, const MKL_INT* ldc, double* work, const MKL_INT* lwork, MKL_INT* info ); ... I see that two arguments with names side_len and trans_len are declared instead of m and n and their order changed when compared to ... void DORM22( const char* side, const char* trans, const MKL_INT* m, const MKL_INT* n, const MKL_INT* n1, const MKL_INT* n2, const double* q, const MKL_INT* ldq, double* c, const MKL_INT* ldc, double* work, const MKL_INT* lwork, MKL_INT* info ); ... >>...Lapack is written in Fortran. We're talking about C declarations and calling these interface functions from C. It means, that a declaration ... void DORM22( const char* side = NULL, const char* trans = NULL, .., .., < skipped > .., .., ) ... is not valid. I think Intel engineers should explain why there is a change in the list of arguments, that is two arguments with different names and positions.

[Mikhail_K_]

The reason I'm asking is because looking at the list of exported symbols in mkl_rt.dll stdcall-decorated DORM22 appears as _DORM22@60

Ie there should be 15 (=60/4) arguments. Header file lists 13, both stdcall and non-stdcall version. They just missed m an n by mistake somehow in mkl_lapack_stdcall.h...

Hint	Function	Entry	Point	Name
2000	(0x07D0)	7418	(0x1CFA)	_DORM22@60
14066	(0x36F2)	11734	(0x2DD6)	_dorm22@60
14068	(0x36F4)	11735	(0x2DD7)	_dorm22_@60

(Anyway, if you look at DGEMM, stdcall-declared header has two more arguments than the non-stdcall one. I'm using both, and its fine. So, string lengths should be in stdcall-headers, I guess, but its not the issue of this thread.)

[Konstantin_A_Intel]

Mikhail,

That's definitely a bug in MKL header file. Thanks for reporting.

Did you try to fix DORM22 declaration manually and to check whether it work or not?

Regards,

Konstantin

[Mikhail_K_]

I'm not really using it, I just parsed the header files and number of arguments does not match number of arguments in the dll-file.

It's easy to fix, but no reason to copy the bug from one version to the next... You may also want to check (they are all declared with 2-3 args less than what dll would indicate):

SORM22
CUNCSD2BY1
DORCSD2BY1
SORCSD2BY1
ZUNCSD2BY1
MKL_CTPPACK
MKL_CTPUNPACK
MKL_DTPPACK
MKL_DTPUNPACK
MKL_STPPACK
MKL_STPUNPACK
MKL_ZTPPACK
MKL_ZTPUNPACK

[Gennady_F_Intel]

thanks for this issue. we will fix into next update. 

[Gennady_F_Intel]

the issue is fixed in MKL v 2018