• In version 10.2 there exist problems with the results from DGEMM, SGEMM, and ZGEMM for very specific input cases and on specific processors. See the knowledgebase article for more information.  The problems are fixed in version 10.2 Update 1.

• Mode DFTI_TRANSPOSE is implemented only for the default case
• Mode DFTI_REAL_STORAGE can have the default value only and cannot be set by the DftiSetValue function (i.e. DFTI_REAL_STORAGE = DFTI_REAL_REAL)
• The ILP64 version of Intel® MKL does not currently support FFTs with any one dimension larger than 2^31-1. Any 1D FFT larger than 2^31-1 or any multi-dimensional FFT with any dimension greater than 2^31-1 will return the "DFTI_1D_LENGTH_EXCEEDS_INT32" error message. Note that this does not exclude the possibility of performing multi-dimensional FFTs with more than 2^31-1 elements; as long as any one dimension length does not exceed 2^31-1
• Some limitations exist on arrays sizes for Cluster FFT functions (Windows* and Linux* versions only). See the reference manual (mklman.pdf) for a detailed description.
• When a dynamically linked application uses Cluster FFT functionality in the Linux* version, the static Intel® MKL interface libraries are also required on the link line. For example: -Wl,--start-group $MKL_LIB_PATH/libmkl_intel_lp64.a $MKL_LIB_PATH/libmkl_cdft_core.a -Wl,--end-group $MKL_LIB_PATH/libmkl_blacs_intelmpi20_lp64.a -L$MKL_LIB_PATH -lmkl_intel_thread -lmkl_core -liomp5 -lpthread
• The negative strides are not been supported by version 10.2 and updates

• The ILAENV function, which is called from the LAPACK routines to choose problem-dependent parameters for the local environment, can not be replaced by a user's version
• second() and dsecnd() functions may not provide correct answers in the case where the CPU frequency is not constant.
• As of version 10.0 the following two issues apply when linking to the dynamic libraries:
  • A user provided XERBLA will not be invoked if LAPACK is called with illegal input parameters. The default XERBLA will be used instead.
  • A user may encounter a segment violation if they call the LP64 interface to LAPACK with illegal parameters. This is because a request may be made to allocate a negative amount of memory.

• Usage of mkl_vml.fi may produce warning about TYPE ERROR_STRUCTURE length
• To create a Windows* DLL that contains references to Intel® MKL functions, the Intel® MKL DLL Builder Tool should be used. Other DLL build techniques are not supported.

• The user can not substitute PJLAENV for their own version. This function is called by ScaLAPACK routines to choose problem-dependent parameters for the local environment.
• On Windows*, there are possible problems with getting global environment variables such as MKL_BLACS_MPI by -genvlist by MPICH2. In this case, try to set all necessary environment variables by using the control panel. From the System control panel select the "Advanced" tab and click the "Environment Variables" button.

• The ILP64 version of Intel® MKL does not contain the complete functionality of the library. For a full listing of what is in the ILP64 version refer to the user's guide in the doc directory.
• g77 can not be used with the ILP64 libraries.

The DHPL_CALL_CBLAS option is not allowed when building the hybrid version of MP LINPACK.

• If you are compiling the Fortran 95 interface to LAPACK with the GNU gfortran compiler, you must manually remove the "pure" attribute from all subroutines containing a procedure argument: ?GEES, ?GEESX, ?GGES, ?GGESX (where ? can be S, D, C, or Z).

• Some Intel® MKL functions contain underscore in their names (i.e. mkl_dcsrsymv, mkl_cspblas_dcsrsymv) and these functions don't support the g77 default naming convention. -fno-second-underscore compilation flag can be used as workaround for this limitation. E.g.: g77 -fno-second-underscore test.f

• To bind with static libraries for the Intel® 64 architecture, you need Xcode* version 2.4.1 as the linkers which come with earlier Xcode* versions fail to bind. This limitation doesn't affect dynamic libraries, nor any IA-32 libraries.
• The Intel® MKL versions earlier than 10.2 update 2 are built by the Intel® C++ Compiler which has the incompatibility problem with XCode 3.2 linker on Mac OS X 10.6 ( Snow Leopard) and as a result Mac OS*X 10.6 doesn't work with static version of libraies when Xcode 3.2 but works when Xcode 3.1.2. Please refer to the article "Linking error on MacOSX 10.6 with XCode 3.2" located here http://software.intel.com/en-us/articles/linking-error-on-macosx-106-with-xcode-32/

• Using /MT when linking with multi-threaded Intel® MKL is recommended. Use of /MD with Microsoft* Visual C++* .NET causes linking errors.

• The Java examples on the Windows* version won't work if the path to the JDK contains spaces. Please use quotes to set JAVA_HOME in those cases. For example: set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_06"

On Intel® processors with Intel® EM64T enabled, user programs compiled with the GNU Fortran compiler (version 3.2.3) will likely get incorrect results from those functions in Intel® MKL that return single precision values, if -fno-f2c GNU Fortran compiler flag isn't used. The GNU Fortran compiler by default expects REAL*4 values in the first 8 bytes of the return register (just as a double precision value would be represented) while the Intel® Fortran compiler expects REAL*4 values in the first 4 bytes of the return register. The behavior of Intel® MKL is compatible with that of the Intel Fortran compiler. GNU Fortran compiler behavior could be changed to be compatible with the Intel Fortran compiler by using the -fno-f2c flag.

FFT and PDE Support functions can not be called from Fortran-77. These components have Fortran-90/95 interface specifics (structures, ..) that can not be used with Fortran-77.

We recommend that -Od on Linux* or /Od on Windows be used for the 10.0 Intel® compilers when compiling test source code available with Intel® MKL. Current build scripts do not specify this option and default behavior for these compilers has changed to provide vectorization.

All VSL functions return an error status, i.e., default VSL API is a function style now rather than a subroutine style used in earlier Intel® MKL versions. This means that Fortran users should call VSL routines as functions. For example:

errstatus = vslrnggaussian(method, stream, n, r, a, sigma)

rather than subroutines:

call vslrnggaussian(method, stream, n, r, a, sigma)

Nevertheless, Intel® MKL provides a subroutine-style interface for backward compatibility. To use subroutine-style interface, manually include mkl_vsl_subroutine.fi file instead of mkl_vsl.fi by changing the line include 'mkl_vsl.fi' mkl.fi (in the include directory) with the line include 'mkl_vsl_subroutine.fi'. VSL API changes don't affect C/C++ users.

In order to achieve better performance, memory allocated by Intel® MKL is not released. This behavior is by design and is a one time occurrence for Intel® MKL routines that require workspace memory buffers. Even so, the user should be aware that some tools may report this as a memory leak. Should the user wish, memory can be released by the user program through use of a function MKL_FreeBuffers()) made available in Intel® MKL or memory can be released after each call by setting the environment variable MKL_DISABLE_FAST_MM (see User's Guide in the doc directory for more details). Using one of these methods to release memory will not necessarily stop programs from reporting memory leaks, and in fact may increase the number of such reports should you make multiple calls to the library thereby requiring new allocations with each call. Memory not released by one of the methods described will be released by the system when the program ends. To avoid this restriction disable memory management as described above.

On Red Hat* Enterprise Linux 3.0, in order to ensure that the correct support libraries are linked, the environment variable LD_ASSUME_KERNEL must be set. For example: 'export LD_ASSUME_KERNEL=2.4.1'

or vice versa message
This can cause performance degradation.

Cause:

Both libiomp5md.dll and libguide40.dll are Intel OpenMP Runtime library. The libiomp5md.dll is new Intel OpenMP* Compatibility library while the libguide40.dll is legacy OpenMP library. Since Intel® MKL 10.1.0.018 and Intel® Compiler 11.x and later,  the default OpenMP runtime library for Intel MKL has been changed from libguide to libiomp.  Please see <http://software.intel.com/en-us/articles/openmp-support-change/>
 
The error is caused by multiple OpenMP libraries were linked in same application. For example, you have two mkl versions MKL 10 and MKL 10.2.1 are linked in same appliation. The error arises because of the duplicate initialization of OpenMP Runtime library from MKL 10 which link libguide40 and MKL 10.2.1 which use libiomp5md .

Please note, the libguide40.dll sometimes were linked implicitly, e.g. by third-party library, custom dll or by dummy library mkl_c.lib in previous MKL version.

Solution:

Please remove one of them and keep only one OpenMP runtime library.

We recommend using and distributing libiomp5md.dll (located in the \bin directory), as libguide40 will be obsolete.

For the third-party library or custom dll which have used the libguide40.dll from pervious  MKL version, in order to avoid such kind of issue, we strongly recommend rebuild your library with libiomp5md.dll.

Limitations to dummy libraries in Intel® MKL 10.0 Update 2:

• Dummy libraries cannot be used in #pragma constructions. Dummy libraries cannot be linked by Intel compiler as a driver. Please see Chapter 3 of User's Guide for more information

Limitations to the sparse solver and optimization solvers in Intel® MKL 10.0 Update 2:

• Sparse and optimization solver libraries functions are only provided in static form

Limitations to the FFT functions in Intel® MKL 10.0 Update 2:

• The function DftiCopyDescriptor is not implemented
• Mode DFTI_TRANSPOSE is implemented only for the default case
• Mode DFTI_REAL_STORAGE can have the default value only and is not changeable by the DftiSetValue function (i.e. DFTI_REAL_STORAGE = DFTI_REAL_REAL)
• The ILP64 version of Intel® MKL does not currently support FFTs with any one dimension larger than 2 ³¹-1. Any 1D FFT larger than 2 ³¹-1 or any multi-dimensional FFT with any dimension greater than 2 ³¹-1 will return the "DFTI_1D_LENGTH_EXCEEDS_INT32" error message. Note that this does not exclude the possibility of performing multi-dimensional FFTs with more than 2 ³¹-1 elements; as long as any one dimension length does not exceed 2 ³¹-1
• Some limitations exist on arrays sizes for Cluster FFT functions. See mklman.pdf for a detailed description
• When a dynamically linked application uses Cluster FFT functionality, it is required to put the static Intel® MKL interface libraries on the link line as well. For example: -Wl,--start-group $MKL_LIB_PATH/libmkl_intel_lp64.a $MKL_LIB_PATH/libmkl_cdft_core.a -Wl,--end-group $MKL_LIB_PATH/libmkl_blacs_intelmpi20_lp64.a -L$MKL_LIB_PATH -lmkl_intel_thread -lmkl_core -lguide -lpthread

Limitations to the LAPACK functions in Intel® MKL 10.0 Update 2:

• The ILAENV function, which is called from the LAPACK routines to choose problem-dependent parameters for the local environment, can not be replaced by a user's version
• second() and dsecond() functions may not provide correct answers in the case where the CPU frequency is not constant.

Limitations to the Vector Math Library (VML) and Vector Statistical Library (VSL) functions in Intel® MKL 10.0 Update 2:

• Usage of mkl_vml.fi may produce warning about TYPE ERROR_STRUCTURE length
• Static Intel® MKL library cannot be linked in case of VML and/or VSL functions usage from shared library
• In case user needs to build custom DLL that contains references to Intel® MKL functions, the Intel® MKL DLL Builder Tool should be used. Other DLL build techniques are not supported

Limitations to the interval arithmetic functions in Intel® MKL 10.0 Update 2:

• The interval libraries will require the libifcore library from Intel® Fortran compiler.
• Interval arithmetic functions require a processor which supports SSE instructions.

Limitations to the ScaLAPACK functions in Intel® MKL 10.0 Update 2:

• The user can not substitute PJLAENV for their own version. This function is called by ScaLAPACK routines to choose problem-dependent parameters for the local environment.
• There are possible problems with getting global environment variables such as MKL_BLACS_MPI by -genvlist by MPICH2. In this case, try to set all necessary environment variables by using the control panel. From the System control panel select the "Advanced" tab and click the "Environment Variables" button.

Limitations to the ILP64 version of Intel® MKL:

• The ILP64 version of Intel® MKL does not contain the complete functionality of the library. For a full listing of what is in the ILP64 version refer to the user's guide in the doc directory.

Limitations to the Java examples:

• The Java examples don't work with static Intel® MKL libraries. Please use the dynamic Intel® MKL libraries for running the Java examples

We recommend that /Od be used for the 10.0 Intel® compilers when compiling test source code available with Intel® MKL. Current build scripts do not specify this option and default behavior for these compilers has changed to provide vectorization.

All VSL functions return an error status, i.e., default VSL API is a function style now rather than a subroutine style used in earlier Intel® MKL versions. This means that Fortran users should call VSL routines as functions. For example:

errstatus = vslrnggaussian(method, stream, n, r, a, sigma)
rather than subroutines:
call vslrnggaussian(method, stream, n, r, a, sigma)

Nevertheless, Intel® MKL provides a subroutine-style interface for backward compatibility. To use subroutine-style interface, manually include mkl_vsl_subroutine.fi file instead of mkl_vsl.fi by changing the line include 'mkl_vsl.fi' in includemkl.fi with the line include 'mkl_vsl_subroutine.fi'. VSL API changes don't affect C/C++ users.

Hyper-Threading Technology (HT Technology) is especially effective when each thread is performing different types of operations and when there are under-utilized resources on the processor. Intel® MKL fits neither of these criteria as the threaded portions of the library execute at high efficiencies (using most of the available resources) and perform identical operations on each thread. You may obtain higher performance when using Intel® MKL without HT Technology enabled.

Memory Allocation: In order to achieve better performance, memory allocated by Intel® MKL is not released. This behavior is by design and is a one time occurrence for Intel® MKL routines that require workspace memory buffers. Even so, the user should be aware that some tools may report this as a memory leak. Should the user wish, memory can be released by the user program through use of a function ( MKL_FreeBuffers()) made available in Intel® MKL or memory can be released after each call by setting an environment variable ( MKL_DISABLE_FAST_MM ) (see User's Guide in the doc directory for more details). Using one of these methods to release memory will not necessarily stop programs from reporting memory leaks, and in fact may increase the number of such reports should you make multiple calls to the library thereby requiring new allocations with each call. Memory not released by one of the methods described will be released by the system when the program ends. To avoid this restriction disable memory management as described above.

Other: GMP and Interval Solver components are located in the solver library. For Intel® 64 and IA-64 platforms these components support only LP64 interface.

Operating System:

Symptoms

When building with Intel® Math Kernel Library for Windows* version 10.0 using the xilink linker from the command line or within the Microsoft Visual Studio* IDE, the following error messages may occur:

Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3)
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3) or(0): internal error: backend signals
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)

When using the Intel® C++ Compiler for Windows*, these errors have occurred when the /Qipo compiler option is used with the xilink linker from the command line.

When using the Intel® Visual Fortran Compiler for Windows*, these errors have occurred when building within the Visual Studio IDE, which uses the xlink linker.

Solution

Intel® Math Kernel Library for Windows version 10.0 introduced new library naming conventions, with "dummy lib" references to the older Intel® MKL libraries. However, there is a format problem with the Intel MKL "dummy libs" files that is causing problems for the Intel xilink tool. Correct the problem by modifying link information for the command line or the Visual Studio link information to specify the new names of the 10.0 Intel MKL libraries.

Linking from the Command Line

When link errors occur, correct the problem by replacing references to the Intel MKL dummy libraries on the link command with explicit references to the libraries listed in the dummy libraries. See the explicit Intel MKL library references listed below.

Linking from within Microsoft Visual Studio

In the Visual Studio IDE, replace the references to the dummy libraries in Project » Configuration Properties » Linker &» Input » Additional Dependencies. See the explicit Intel MKL library references listed below.

For IA-32 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_c_dll.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_s_dll.lib mkl_intel_s_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_c.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib mkl_s.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib mkl_scalapack_dll.lib mkl_scalapack_core_dll.lib mkl_scalapack.lib mkl_scalapack_core.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib

For Intel® 64 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_em64t.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib.lib mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib mkl_scalapack.lib mkl_scalapack_lp64.lib mkl_solver.lib mkl_solver_lp64.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib

For IA-64 [Intel® Itanium®] Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_ipf.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib mkl_scalapack.lib mkl_scalapack_lp64.lib mkl_solver.lib mkl_solver_lp64.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib