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
#define MKL_INT64 long long int
#define MKL_UINT64 unsigned long long int
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.
It is futile to attempt using 64-bit MKL libraries using a 32-bit C compiler. Apart from the 64-bit signed integer problems that you brought up, pointer size, instruction set and ABI are mismatched, and the RTL is unsuitable.
The first line of the code snippet that you included from mkl.h contained " MKL integer types for LP64 and ILP64 ", and I (incorrectly, it now appears) took it for granted that you were using the LP64 or ILP64 libraries. For the same reason, I did not bother to check whether these lines in mkl.h might remain after preprocessing in 32-bit mode.
MKL does not support Borland C++ compiler. This is the full list of C/C++ compilers supported on Windows. See more information about MKL system requirments here: http://software.intel.com/en-us/articles/intel-mkl-110-system-requirements/
Supported C/C++ and Fortran compilers for Windows*:
- Intel® Visual Fortran Composer XE 2013 for Windows* OS
- Intel® Visual Fortran Compiler 13.0 for Windows* OS
- Intel® Visual Fortran Compiler 13.1 for Windows* OS
- Intel® C++ Composer XE 2013 for Windows* OS
- Intel® C++ Compiler 13.0 for Windows* OS
- Intel® C++ Compiler 13.1 for Windows* OS
- Microsoft Visual Studio* 2011 - help file and environment integration
- Microsoft Visual Studio* 2010 - help file and environment integration
- Microsoft Visual Studio* 2008 - help file and environment integration
- Microsoft Visual Studio* 2005 Team Suite Edition - help file and environment integration
- Microsoft Windows* SDK for Windows* 7 (Intel® 64)
- Microsoft Windows* Software Development Kit Update for Windows Vista* (Intel® 64)
- Microsoft Windows Server* 2003 R2 Platform SDK (Intel® 64)
- Microsoft Windows* Software Development Kit for Windows Server* 2008
- PGI* Workstation Complete version 12.5
I am just a casual user of C, but it seems to me that replacing long long int with __int64 would reduce portability. The C99 standard (see for example http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, section 126.96.36.199) specifies long long int to be a standard integer type. There is no mention of __int64 in the document, and GCC does not recognize it as a native type; perhaps it is a Microsoft C extension that is also supported by Borland C.
Thank you very much for your extensive notes. We will take this into consideration as part of our ongoing effort of making MKL more portable. If you know more about how widely Borland C++ compiler and other legacy compilers are still used in some organizations, please let us know your insight. This will help us to justify our effort.
As I understand the main problem here is in customization of MKL types. Please look at corresponding KB article http://software.intel.com/en-us/articles/use-of-intel-mkl-data-types-in-cc-applications. Maybe, MKL_UINT64 should allow such customization too as it is done for MKL_INT. However, MKL is common library for C/C++ and FORTRAN. But FORTRAN has no unsigned interger types. Therefore, MKL_UINT and MKL_UINT64 types are kind of C-related compromises in MKL interfaces which look like unnecessary.