Intel Software Network articles Feed

*TRMV bug for large problems in threaded operation

Tue, 01 Feb 2011 00:00:00 -0800

Reference Number: DPD200165114

Product: Intel® Math Kernel Library (Intel® MKL)

Versions: Intel® Math Kernel Library 10.3 Update 2 and earlier versions with code optimizations for processors based on the Nehalem micro-architecture and later

Operating System: All supported operating systems

Problem description:

The BLAS level 2 functions (*TRMV) which perform the product of a triangular matrix and a vector provide incorrect results when run in threaded mode with matrices of dimension 3000 or larger. The bug is part of a code path which is dispatched on processors based on the Nehalem micro-architecture and later. This includes the Intel® Xeon processors 5500 and 7500 series and the Intel® Core™ i7 processor and those introduced since their introduction.

Workaround:

The problem does not occur when linking the sequential version of the library. The problem does not occur when threading is turned off using any of the means available (see "Managing performance and memory" chapter of the Intel MKL User's guide). For example, you may bracket your calls to DTRMV with calls to mkl_set_num_threads(), temporarily turning threading off for large sizes.

Resolution status:

A fix for this problem is available in Intel MKL 10.3 update 3.

MKL CFFT examples fail with MPICH2 on Windows* Itanium machine

Wed, 08 Dec 2010 07:30:00 -0800

Reference Number :
DPD200198806

Version :
Intel® MKL 10.2.4 and later

Product :
Intel® Math Kernel Library

Operating System :
Microsoft Windows*

Problem Description :

CFFT examples in Intel MKL fail with MPICH2 on Windows Itanium machine. The route cause for this problem is that MPICH2 (mpiexec.exe) does not process values of environment variables (e.g. PATH) longer than 260 characters (MAX_PATH defined in windef.h).

Starting with Intel® MKL 10.2.4 examples were compiled/linked with /Qopenmp which caused threading libs conflict with 10.1 compiler.

Resolution Status :

The fix for this is avaialble in MKL 10.2.7, and examples were changed to follow Intel’s recommendation to use dynamic OpenMP libraries (libiomp5.dll). The MKL binaries are not modified, hence current customers’ applications are not impacted.

As a workaround for now, we recommend the below two options now.

1. Make sure your PATH is shorter than 260 characters or set your system PATH to include required paths.

2. Copy all dependant DLLs to the folder which contains the executable.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

How to select different update of Intel® Composer XE 2011 for Linux* and Mac OS* X

Mon, 06 Dec 2010 08:00:00 -0800

Reference Number : dpd200194608, dpd200160631

Version : 2011 (Compiler 12.0)

Product : Intel Composer XE

Operating System : Linux, Mac OS X

Problem Description : When an Intel Composer XE update is installed, the scripts compilervars.sh [.csh] in the bin directories of previously installed compilers no longer set the environment for the corresponding compiler or update, but set the environment for the most recent update instead. This applies to all components of Intel Composer XE that may be present: C/C++ and Fortran Compilers; Intel Debugger; Intel Threading Building Blocks; Intel Math Kernel Library and Intel Performance Primitives.

Workaround:

To select a compiler update other than the latest, please use the script compilervars_arch.sh [.csh] from the bin directory of the desired compiler version. Similarly, for other components of Intel Composer XE, use the scripts idbvars.sh, tbbvars.sh, mklvars.sh and ippvars.sh from the bin directory of the desired version, as needed.

Resolution Status:
The issue has been fixed in Composer XE update #4. To select a specific version, use the compilervars.[c]sh script from the version-specific directory. For example, after installing update #4 on a system where update #3 was already installed:

> source /opt/intel/composerxe-2011.3.174/bin/compilervars.sh intel64 <<<=== update #3

> ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.3.174 Build 20110309

> source /opt/intel/composerxe-2011.4.191/bin/compilervars.sh intel64 <<<== update #4

> ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.4.191 Build 20110427

As before, the script from the generic, non-version specific directory will initialize for the most recent update:

> source /opt/intel/composerxe-2011/bin/compilervars.sh intel64 <<<=== non-version specific (most recent update)
> ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.4.191 Build 20110427

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Problem with Intel(R) MKL DSS Single Precision version

Tue, 12 Oct 2010 11:30:00 -0700

Reference Number : DPD200192258

Version : versions 10.2 Update 6 and 10.3 beta

Product : Intel(R) MKL

Operating System : all supported by Intel(R) MKL at this moment

Problem Description :

The F90 DSS interface is broken because of currently DSS API supports Double Precision data types only.
Compilation DSS interfaces with Single Precision Data types will produces something like the following compilation errors

dss_sym_f90.f90(78): error #6633: The type of the actual argument differs from the type of the dummy argument. [VALUES]
dss_sym_f90.f90(82): error #6633: The type of the actual argument differs from the type of the dummy argument.

[RHS]
dss_sym_f90.f90(82): error #6633: The type of the actual argument differs from the type of the dummy argument. [SOLUTION]
dss_sym_f90.f90(89): error #6633: The type of the actual argument differs from the type of the dummy argument. [STATOUT]

Workaround:

As a temporarily workaround, we would recommend you to do the following:
1) make the call call DSS_CREATE( handle, MKL_DSS_SINGLE_PRECISION)
and then
2) manually change the API of these functions ( mkl_dss.f90 which is located in firectory ) by replacing REAL(KIND=8) by REAL(KIND=4) into those routines, which have been used into your application.

As an example, please see the MKL Forum tread, where the similar problem has been discussed.

Resolution Status :
fixed the next Update - 10.2 Update 7 and 10.3 Update 1

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Dynamic MKL OOC PARDISO cannot solve large problem on Win64 bit OS.

Thu, 30 Sep 2010 11:30:00 -0700

Reference Number : DPD200193362

Version : 10.2 Update 6, 10.3 beta 2

Product : Intel(R) Math Kernel Libary

Operating System : Windows, 64 bits

Problem Description :

During solution of pretty big tasks with OOC mode of PARDSIO on Win64 OS ( Win7 )
with Dinamic linking mode

PARDISO generates the next report:
Fseek failed
*** Error in PARDISO ( numerical_factorization) error_num= -987
*** Error in PARDISO: zero pivot

The issue happens independently of type of solved matrixes.

Root Cause:

This problem occurs because of there is unresolved reference _fseeki64 into dynamic libraries of Intel(R) MKL on Win64 OS.

Workarounds:
Using statically linking mode instead of dynamic.

Resolution Status :

the fix of this issue will available the next versions: 10.2 Update 7 and 10.3

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

MKL performance degradation on SGI ALtix UV system with Nehalem EX processor

Sun, 18 Jul 2010 11:30:00 -0700

Reference Number : DPD200155507

Version : Intel® MKL 10.2.Update5 and earlier

Product : Intel® Math Kernel Library (Intel® MKL)

Operating System :
Red Hat Enterprise Linux* 5
SuSE Linux Enterprise Server* 10

Problem Description :
MKL experiences the performance degradation in the case dgemm when MKL works on
on SGI Altix systems with Nehalem-EX CPU.
The cause of the problem is that MKL wrong detects number of threads which are available on this type of system

Resolution Status :
The problem has been fixed and is available in the versions of Intel® MKL 10.2 Update 6 and later versions.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

dgelsd returns the error when is running on AMD processor

Sat, 17 Jul 2010 11:30:00 -0700

Reference Number: DPD200186199

Version: Intel® MKL 10.3 beta

Product : Intel® Math Kernel Library (Intel® MKL)

Operating System :

Red Hat Enterprise Linux* 5
SuSE Linux Enterprise Server* 10

Problem Description :

MKL routine dgelsd (Computes the minimum-norm solution to a linear least squares problem using the singular value decomposition of A and a divide and conquer method)

returns the error message: "MKL ERROR: Parameter 4 was incorrect on entry to DLASCL" when dgelsd is running on AMD processor(model name : AMD Opteron(tm) Processor 250)

In the particular testcase provided by mkl's customer dgelsd computes a solution to a linear equation system:

A*x = b

where A is 76x76 matrix (see into attachment), b is a right-hand side vector, b(i) = 1.0, 1 <= i <= 76.

The Cause of the Problem:

The issue has been reproduced and investigated. The root cause is high instability of the divide-and-conquer algorithm on near singular matrices. Some of the singular values appeared to be very close to zero as the others are in the range 1-1000. The smallest singular values computed are:

s(73) = 8.133105e-12
s(74) = 3.960993e-12
s(75) = 6.003114e-13
s(76) = 4.341465e-13

The error message above appeared due to the slow convergence of the singular value update process implemented in dlasd4 auxiliary routine - the algorithm failed to converge by the preset number of iterations, as a result NaNs happened in the internal computations, propagated to the dlascl routine scaling an intermediate matrix.

Resolution Status :

The problem has been fixed and the fix is available in the versions of Intel® MKL 10.2 Update 6 and later.

Optimization Notice
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804

fmod (math.h) returns a garbage number if it's called right after some Lapack's routines.

Sun, 30 May 2010 11:30:00 -0700

Problem :

fmod (math.h) returns a garbage number if it's called right after dsyevr or zheevr.

The returned result is:
fmod(1.000000, 2.000000) = -1.#IND00

while the expected result is:
fmod(1.000000, 2.000000) = 1.000000

See attachment for the code example to reproduce the problem.

Environment :

Windows XP, Windows 7, 64bit

Affected Versions:
Intel® MKL 10.2 ( all updates 1,.,5). No issue with earlier versions like 10.1, 10.0..

Root Cause :

This problem occurs because of a bug in the Microsoft assembly code in the x64 fmod function. When the function checks the x87 status word for the denormal flag, the function incorrectly assumes that an error occurs.
For more info please refer to the article : http://support.microsoft.com/kb/972497:

It should be noted that despite the fact that Microsoft claims that the problem is visible only with VS 2008, the problem described in this article with using MKL’s routine, reproduced with Visual C++ 2005 and 2010 also.

Workarounds:

Using Intel(R) C/C+ Compiler (64 bit) eliminates the problem as the issue happens if Microsoft C/C++ Compiler is used.

Resolution Status:

See the update of the problem on Microsoft Side.

Intel® MKL 10.3 Bug Fixes

Fri, 21 May 2010 00:00:00 -0700

The tables below summarize specific customer issues or feature requests that have been addressed by the indicated product releases. Some items span multiple architectures and/or operating systems and some relate only to a single architecture or operating system.

NOTE: The issues, defects, bug reports, and feature requests described below represent specific issues with specific test cases. An item listed here does not imply that it necessarily applies to your application(s). If your situation does not match the specific test case you may not have experienced the error or problem associated with that update. It is not possible to describe the details of every issue and its specific test case in these tables.

Providing a complete description of each item in the list below is impractical. For that reason we ask that you post a message on the Intel MKL user forum, http://software.intel.com/en-us/forums/intel-math-kernel-library/, and reference this page and the "DPD" number associated with the item of interest, if you have questions regarding the information in these tables.

These tables are updated regularly to correct any errors and omissions.

Intel® MKL 10.3 update 10 (30 April 2012)


DPD200274946	{S\|D}STERM description in the Intel MKL reference did not mention that parameter 'd' will be overwritten
DPD200274901	PARDISO:division by zero occurs when trying to solve unsymmetric matrices
DPD200272909	Trailing underscores ( e.g - "fftwnd_f77_mpi_" ) are missing in the F77 interface wrappers
DPD200180544	Performance regression in *SYEV
DPD200270801	MT19937/MT2203 generator results when obtained all at once in a single array are different from results obtained in multiple subsets
DPD200274331	Performance issue of cblas _?nrm2 on processors supporting Intel Advanced Vector Extensions (Intel AVX)
DPD200276708	PARDISO does not solve the diagonal matrix

Intel® MKL 10.3 update 9 (18 February 2012)


DPD200175424	IDAMAX can return bad index - (note: can cause heap corruption in other MKL functions. e.g., DGETRF DPD200274016)
DPD200211015	Poor scaling of double-precision 2-power 1d FFT on ia32
DPD200267589	Updated MKL User Guide to reflect the latest version XCode
DPD200263102	Error in local PARDISO version report in 10.3.7 did not change from 10.3.6 - It is still 103000116
DPD200177488	DAXPY performance degradation for small sizes when using multiple threads
DPD200225339	Performance regression for several functions from 10.3.4 to 10.1.1

Intel® MKL 10.3 update 8 (19 December 2011)


DPD200172281	Bug in 1D FFT with DFTI_BACKWARD_SCRAMBLED with N>=16384
DPD200223467	Bug in error message for vslSaveStreamF
DPD200231975	Heap corruption occurs when calling SetThreadAffinityMask() before any Intel MKL functions (workaround: call mkl_set_num_threads() first)
DPD200261042	DftiCommitDescriptor craches for 1D FFT setup when DFTI_NUMBER_OF_TRANSFORMS > 1 and dynamic linking is used

Intel® MKL 10.3 update 7 (25 October 2011)


DPD200225521	Conflict from use of MKL_PARDISO as threading domain and module name
DPD200216996	Problem with PDTRAN function in case of P=2 and Q=2
DPD200228197	PARDISO problem when solving a new system after initial solve with diagonal matrix
DPD200230260	PARDISO fails on IA32 for large systems with more than 250 million LU factors

Intel® MKL 10.3 update 6 (6 September 2011)


DPD200218547	PARDISO may return #IND values in the solution vector
DPD200219651	zgetc2 performance degradation when dynamically linked or on 64-bit architectures
DPD200221246	Line 188 in mkl_pblas.h won't compile unless changed to PZTRANC( MKL_INT m, MKL_INT n
DPD200221247	two unresolved symbols in mkl_scalapack_ilp64.lib(pxerbla.obj)

Intel® MKL 10.3 update 5 (4 August 2011)


DPD200169403	Problem with using max value for an upper bound in the trust region solver.
DPD200169895	Bug in PARDISO symbolic factorization when solving indefinite non-symmetric double complex matrices
DPD200192242	The validity of input values is now checked to prevent the solver from hanging
DPD200210337	PARDISO OOC: .sin and .sle files remain after execution
DPD200210595	mkl_zcsradd produces incorrect results for the array sizes set according to the Manual
DPD200212849	DSTEGR function seg faults for many cases when linked dynamically or with LP64 interface
DPD200214225	Attempts to convert a CSR matrix to BSR format with mkl_dcsrbsr using JOB(6)=-1 fail with input error message
DPD200214530	Run-time problems when mkl_thread_free_buffers() is the first MKL function called on a thread
DPD200218547	PARDISO may return #IND values in the solution vector

Intel® MKL 10.3 update 4 (12 May 2011)


DPD200209064	mkl_zdnscsr produces incorrect results when estimating memory for conversion of double precision complex dense matrices to the CSR format
DPD200207760	Iterative refinement and CGS iterations errantly invoked when partial solving step (Fw, Diag or Bw) is requested in PARDISO
DPD200167242	OpenMP settings are ignored by Intel MKL after a single call to DSYRK
DPD200207682	Out-of-core (OOC) PARDISO factorizes the first matrix but fails to factorize further matrices in the "same topology" mode
DPD200199308	In-core PARDISO generates wrong result with a single test data if number of threads is 32
DPD200167236	Syntax error in mklvars.csh
DPD200204522	DGESDD returns U and VT outputs that are not orthogonal enough
DPD200168437	Performance degradation of VML functions in threaded environment

Intel® MKL 10.3 update 3 (29 March 2011)


DPD200205256	ZGESVD in multithreaded MKL produces wrong results
DPD200165165	DGETRF returns different results on consecutive runs
DPD200203834	Many warnings when building a custom static library based on the Intel MKL library
DPD200196299	ScaLAPACK LU test program fails to run on 1024 node cluster
DPD200083045	mkl_gmp.h causes compile time error C++ codes
DPD200206509	scgemm/dzgemm errors
DPD200199131	PDGEMR2D: out of memory error even when using 64-bit libraries
DPD200192508	PARDISO is 2x slower than SuperLU for some data
DPD200151246	Performance scalability problem for DGEMM on Win32 on 8 threads
DPD200204717	Real VML functions outperform the complex VML functions more then 20 times
DPD200165114	*TRMV provides wrong results for problems larger than 3000 for multi-threaded cases

Intel® MKL 10.3 update 2 (31 January 2011)


DPD200090962	Expanded threading to new cases for multi-dimensional transforms
DPD200133579	Solved problem of large 1D descriptors without performance degradation
DPD200198147	Calls to blacs_exit before initialization routines no longer causes a crash
DPD200198405	VML functions crash or get incorrect results when called from within Linux native threads in ILP64 mode
DPD200199435	Performance degradation of VML functions when using native threading and linking DLLs on Windows
DPD200202108	Access violation caused by corruption of the PARDISO handle when called multiple times with only a single handle initialization

Intel® MKL 10.3 update 1 (3 December 2010)


DPD200192242	Trust Region Solver hangs
DPD200132424	Full support for TR single precision solvers
DPD200162063	Error in ?LATRD output parameter description in reference manual
DPD200194170	Performance degradation in VML functions Add, Sub, Mul in 10.2.5 (and 10.3) for Intel® Pentium® 4 processors on Windows*
DPD200185620	DGEQP3 scales poorly on multiple threads

Intel® MKL 10.3 (9 November 2010)


DPD200095498	Unclassifiable error in PARDISO when MKL_PARDISO_OOC_MAX_CORE_SIZE=200 is set
DPD200186873	clapack_dgbtrf returns the wrong results
DPD200186934	mkl_dcsrcoo produces the wrong output if nnz is not initialized explicitly
DPD200187697	dss_factor_complex crashed with invalid floating op when /Qtrapuv
DPD200192952	Documentation bug in MKL-Lapack95 GESDD
DPD200084190	PARDISO OOC will now run parallel code for all supported matrix types
DPD200087174	ippGenNumCoresOndie symbol in Intel MKL conflicts with IPP when used simultaneously
DPD200092652	Incorrect results for mkl_dcsrcsc when using 0-based indexing
DPD200091197	Intel MKL FFT performance deficiency on non-power-two vector sizes
DPD200090409	Add Fortran 90 include path in MKL environment setup scripts
DPD200149638	Intel MKL doesn't contain CDFT interface in shared libraries
DPD200085280	Intel MKL CFFT: Lack of scalability on non power of 2 core-counts
DPD200154738	Path variable corrupted with quote characters after running mklvars.bat
DPD200084778	Examples for calling PARDISO from Fortran 90

ZGESV returns the wrong result on Mac LP64 NHM system if MKL is linked statically.

Sat, 10 Apr 2010 11:30:00 -0700

Reference Number : DPD200153565

Version : Intel® MKL 10.2 ( all updates 1,.,4)

Operating System : Mac OS, 64bit
System Version: Mac OS X Server 10.6.2 (10C540)
Kernel Version: Darwin 10.2.0
$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

Problem Description :

If you compile and run zgesv.c ( see the whole test into attachment), you will see something like below, but the expected results should be
x_exact == x.

With MKL dynamic linking, everything seems to be ok.

$ ./zgesv
MKL Version = 10.2 Updates ( 3,4)
Processor optimization : Intel(R) Core(TM) i7 Processor, CPU frequency = 2.26 GHz

x_exact[0] = {1.000000, 0.000000}
x_exact[1] = {1.000000, 0.000000}
x_exact[2] = {1.000000, 0.000000}

info = 0
x[0] = {0.705114, 0.421455}
x[1] = {0.346944, 0.484740}
x[2] = {0.314761, -0.157588}

Test machine : MacPro 8-core 2.26GHz Nehalem.
MKL link : $(MKLPATH)/libmkl_intel_lp64.a $(MKLPATH)/libmkl_intel_thread.a $(MKLPATH)/libmkl_core.a -L$(MKLPATH) -liomp5

Workarounds:
1) Use another build of gcc, not 5659 ( for example
The problem doesn't appear with gcc 4.0.
i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.
2) Instead of 'gcc' call directly executable 'i686-apple-darwin10-gcc-4.2.1'.

3) Use dynamic linking instead of static

Resolution Status :

The problem is under investigation at this moment.
We will update the reason of the problem immediately when the cause of the problem has been discovered.

Resolution Note:
the problem has been fixed and the fix available in Intel(R) MKL versions since 10.2.Update 6 and in version 10.3 Gold.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]