Inconsistencies with declaration of 64-bit integers ( signed and unsigned ) in many MKL functions

[SergeyKostrov]

There are inconsistencies with declaration of 64-bit integers ( signed and unsigned ) in many MKL functions. In mkl_types.h there is a declaration:

/* MKL integer types for LP64 and ILP64 */
#if (!defined(__INTEL_COMPILER)) & defined(_MSC_VER)
    #define MKL_INT64 __int64
    #define MKL_UINT64 unsigned __int64
#else
    #define MKL_INT64 long long int
    #define MKL_UINT64 unsigned long long int
#endif

So, MKL_INT64 type is a portable declaration. However, in many MKL functions non-portable declarations long long int and unsigned long long int are used. It creates lots of problems if some legacy C++ compilers are used. For example, Borland C++ v5.x doesn't support  long long int and unsigned long long int types.

[barragan_villanueva_]

Sergey,

My previous post was for your Note1. In my opinion, it’s better to allow/use customization of MKL types instead of collection of all type variants for currently available compilers.

See my comments below on other your Notes2-4.

2) As to mkl_lapacke.h. It is interface for LAPACKE component and it is already part of mkl.h header.

3) As to CDECL/STDCALL calling convention for MKL functions. You know not all functions in MKL can have types of calling conventions. For example some DFTI functions are defined with ellipsis which is not allowed for STDCALL. Maybe some corrections are required to fix MKL interfaces if they need CDECL/STDCALL. We need to check it for CBLAS you mentioned.

4) As to control inclusion of all MKL headers files in mkl.h. I don’t like your suggestion introducing additional macros for including MKL components. In my opinion mkl.h is common MKL header file which includes all MKL components. But if some application needs just several of them it’s better to list them directly instead of mkl.h.

For example to use LAPACKE and SERVICE components:

#include “mkl_types.h”

#include “mkl_lapacke.h”

#include “mkl_service.h”

[SergeyKostrov]

>>...As I understand the main problem here is in customization of MKL types... No. Declarations of MKL functions should Not use any unwrapped types and see my previous posts.

[SergeyKostrov]

Here is example: Currently declared ... /* SkipAheadStream - skip-ahead method */ #if defined( _MSC_VER ) _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const __int64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const __int64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const __int64 *)) #else _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const long long int )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const long long int *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const long long int *)) #endif ... A modified version 1 ... /* SkipAheadStream - skip-ahead method */ #if defined( _MSC_VER ) _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const __int64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const __int64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const __int64 *)) #else _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const MKL_INT64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const MKL_INT64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const MKL_INT64 *)) #endif ... Or A modified version 2 ... /* SkipAheadStream - skip-ahead method */ _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const MKL_INT64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const MKL_INT64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const MKL_INT64 *)) ... Note: Both versions of modifications Don't change internals of these MKL functions and could be applied very easily ( this is what I was forced to do ).

[SergeyKostrov]

>>...I don’t like your suggestion introducing additional macros for including MKL components. In my opinion... I don't think a final decision should be based just on your or my opinions. I regret to see that in some cases developers are trying to "...make an elefant from a fly..." and ready to discuss some subject for weeks if not months when very simple solutions exist.

[barragan_villanueva_]

Sergey,

Firstly, you suggested to change MKL_UINT64 definition to comply with Borland C++. So I said that it's your main problem which can be resolved via customization of MKL_UINT64 type.

As to your comments related to SkipAheadStream definitions, you are right they should use MKL_INT64 type.

[SergeyKostrov]

Did you read my previous post? I gave a clear example of some problem with declaration of several MKL functions: Currently declared ... /* SkipAheadStream - skip-ahead method */ #if defined ( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) _mkl_api( int, vslskipaheadstream, (VSLStreamStatePtr *, const __int64 * ) ) _MKL_API( int, VSLSKIPAHEADSTREAM, (VSLStreamStatePtr *, const __int64 * ) ) #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) _mkl_api( int, vslskipaheadstream, (VSLStreamStatePtr *, const long long int * ) ) _MKL_API( int, VSLSKIPAHEADSTREAM, (VSLStreamStatePtr *, const long long int * ) ) #endif ... Once again, these are codes implemented by Intel software developer and they have Non Portable data types long long int and __int64. Consider it as a bug that could be fixed in less than one minute. Sorry, but we spent more time on writing and reading posts in that thread.

[SergeyKostrov]

>>...So I said that it's your main problem which can be resolved via customization of MKL_UINT64 type. Yes, I can do customization and this is actually what I've done by modifying several MKL header files. Now, the main concern / problem is that as soon as another developer ( it is out of my control ) will update MKL all these modifications will be gone. Of course, I could make some instructions but, you know, they could be ignored, or forgotten, etc. Looking ahead I see that as soon as a new update of MKL is installed compilation of sources will be broken if my instructions are not followed by. Also, I've just completed a verification with MinGW C++ compiler and it perfectly works with long long int-like data types and in overall it took me less than 2 hours to integrate MKL and MinGW. My conclusion is that MKL could be used with legacy C++ compilers, like Borland ( 32-bit only ), and with GCC-like C++ compiler for Windows, like MinGW ( 32-bit & 64-bit ), but some modifications currently needed in MKL header files. A good thing is that these modifications are very small and don't affect internal implementations of any MKL functions. So, if my suggestions will be applied some time in the future it will be awesome. Thank you in advance.

[SergeyKostrov]

Just for consistency with currently used #ifdefs in another header files: Instead of ... /* SkipAheadStream - skip-ahead method */ #if defined ( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) ... #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) ... #endif ... I think a verification for __INTEL_COMPILER is needed ... /* SkipAheadStream - skip-ahead method */ #if ( !defined( __INTEL_COMPILER ) ) & defined( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) ... #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) ... #endif ...

[Bernard]

>>>perhaps it is a Microsoft C extension that is also supported by Borland C.>>>

__int64 is Microsoft type specifier.

[SergeyKostrov]

>>>>...is a visual studio compatible implementation of stdint.h. I see advantages in such additions to promote portable >>>>use of data types... >> >>I see now where the root cause of the problem is and technical details will be provided after I'll look at some headers from >>all C++ compilers I use. I still didn't have time to look at it and I hope that I'll do it tomorrow.

[SergeyKostrov]

Additional verification shows that these four legacy C/C++ compilers do not support declarations long long int and unsigned long long int: Borland C++ v5.x Visual C++ 6.x ( also known as Visual Studio 98 ) Turbo C++ v3.x Turbo C++ v1.x Even if all tested C/C++ compilers ( released after 2000 ) support these declarations I don't see any reason to support them in MKL because __int64 and unsigned __int64 built-in types exist. By the way, Intel's intrinsic headers do not have these declarations at all and all 64-bit types are based on __int64 and unsigned __int64 built-in types.

[SergeyKostrov]

#include "stdio.h" typedef long int LINT; typedef long long int LLINT; LINT liValue = 0; LLINT lliValue = 0; int main( void ) { printf( "sizeof( LINT ) = %d\n", sizeof( LINT ) ); printf( "sizeof( LLINT ) = %d\n", sizeof( LLINT ) ); return ( int )0; }

[SergeyKostrov]

Zhang, Victor, This is simply to let you know that the same modifications with MKL header files are needed in case of using MKL version 11.0.2 with Borland C++ compiler version 5.x. A good thing is MKL functions also perfectly work.

[SergeyKostrov]

This is a message for David regarding integration of MKL with Borland C++ compilers: David, Please do not send me messages using IDZ Messaging System since I'm no longer using it. Sorry about it.

[SergeyKostrov]

>>This is a message for David regarding integration of MKL with Borland C++ compilers: >> >>David, >> >>Please do not send me messages using IDZ Messaging System since I'm no longer using it. Sorry about it. David, Could you provide some update on a status of your work related to integration of MKL with a version 10 of Borland C++ compiler? Could you also provide more details about the compiler? Thanks.