Mac LP64 zgesv returns a wrong result

[jaewonj]

Mac LP64 zgesv returns a wrong answer if MKL is linked statically. It seems
this only happens on I7 CPU.

If you compile and run zgesv.c (attached), you will see something like below,
but I expect x_exact == x. With MKL dynamic linking, everything seems to be ok.

$ ./zgesv

MKL Version = 10.2.3
Processor optimization : Intel Core 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

Could you check this on your side? Thanks.

Jaewon

-----------------------------------------------------------------------
/* zgesv.c */

#include
#include
#include
#include "mkl.h"
#include "mkl_service.h"
#include "mkl_lapack.h"

static void print_mklinfo()
{
MKLVersion ver;
MKLGetVersion(&ver);
printf("\\nMKL Version = %d.%d.%d\\n", ver.MajorVersion, ver.MinorVersion, ver.UpdateVersion);
printf("Processor optimization : %s\\n", ver.Processor);
printf("CPU frequency = %.2f GHz\\n\\n", getcpufrequency());
}

static void run_zgesv()
{
char trans = 'N';
MKL_INT i, n = 3, nrhs = 1, lda = 3, ldb = 3, info, ipiv[3];
MKL_INT incx = 1, incy = 1;
MKL_Complex16 alpha = {1., 0.}, beta = {0., 0.}, b[3];
MKL_Complex16 a[9] = {
{-2., 1.}, {0., -1.}, {0.5, 0.25},
{1., -1.}, {-2., 1.}, {0., -1.},
{0., 0.}, {1., -1.}, {-2., 1.}};
MKL_Complex16 x_exact[3] = {{1., 0.}, {1., 0.}, {1., 0.}};

for (i = 0; i < n; i++)
printf("x_exact[%d] = {%f, %f}\\n", i, x_exact.real, x_exact.imag);
printf("\\n");

zgemv(&trans, &n, &n, α, a, &lda, x_exact, &incx, β, b, &incy);
zgesv(&n, &nrhs, a, &lda, ipiv, b, &ldb, &info);

printf("info = %d\\n", info);
for (i = 0; i < n; i++)
printf("x[%d] = {%f, %f}\\n", i, b.real, b.imag);
printf("\\n");
}

int main()
{
print_mklinfo();
run_zgesv();
return 0;
}

[Gennady_F_Intel]

jaewonj,

we tried to reproduce the problem on RHEL*5, the example passed, see the log below:

MKL Version = 10.2.3
Processor optimization : Intel Core i7 Processor


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] = {1.000000, 0.000000}

x[1] = {1.000000, -0.000000}

x[2] = {1.000000, 0.000000}

--Gennady

[Artem_V_Intel]

Hello Jaewon,

I tried to reproduce this problem on Intel Core 2 Duo processor running Mac OS 10.6 'Snow Leopard' and doesn't obtain any issues. I linked this app against MKL 10.2.4. Please see logs for LP64 and ILP64 modes below:

LP64:

MKL Version = 10.2.4
Processor optimization : Intel Core 2 Duo Processor
CPU frequency = 1.99 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] = {1.000000, 0.000000}
x[1] = {1.000000, -0.000000}
x[2] = {1.000000, 0.000000}

ILP64:

MKL Version = 10.2.4
Processor optimization : Intel Core 2 Duo Processor
CPU frequency = 2.00 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] = {1.000000, 0.000000}
x[1] = {1.000000, -0.000000}
x[2] = {1.000000, 0.000000}

Best regards,

Artem

[jaewonj]

Gennady,

This is weird. I can reproduce the problem everytime I run the example code. Is it possible for you to compile the example with MKL static link and run on Mac Pro (2.26GHz, 2 Quad-Core Intel Xeon Nehalem processor)?

Jaewon

[jaewonj]

Updated to 10.2.4, but doesn't help. ZGESV still returns a wrong solution.

[Todd_R_Intel]

Jaewon,

I ran your code on a 2.66GHz 8-core Intel Xeon processor (Nehalem) and still do not see the problems you report when linking statically. Could you say something about the OS and gcc version you are using?

-Todd

[jaewonj]

Todd,

Here is gcc, system, and os information. You can find CFLAGS and LDFLAGS in the screen shot attached before. Please let me know in case you need futher information.

Thanks.

Jaewon

$ system_profiler | more

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.26 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB

System Software Overview:

System Version: Mac OS X Server 10.6.2 (10C540)
Server Configuration: Advanced
Kernel Version: Darwin 10.2.0
Boot Volume: 10.6
Boot Mode: Normal
Computer Name:
User Name: Jaewon Jang (jaewonj)
Secure Virtual Memory: Not Enabled
64-bit Kernel and Extensions: Yes
Time since boot: 31 days 18 minutes

$ 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.

[jaewonj]

Any update on this issue? Thanks.

[Todd_R_Intel]

Jaewon

Here is the information I see on our system. The OS, kernel, and gcc are older versions. I'll ask

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB

System Software Overview:

System Version: Mac OS X Server 10.5.8 (9L34)
Kernel Version: Darwin 9.8.0
Boot Volume: XserveHW
Boot Mode: Normal
Computer Name:
User Name:
Time since boot: 14 days 4:11


PLL-Xserve:u72449 trosenqu$ gcc --version

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 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.



I'll continue to investigate.

Todd

[Alexander_K_Intel3]

Jaewon,

Could you please try different compiler (another version of gcc, or icc or anything else) to look if issue still appears.

I'm also trying to reproduce your issue, but still not succesfull.
My envoronment is almost the same:

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB
Memory: 12 GB
Processor Interconnect Speed: 6.4 GT/s
Boot ROM Version: XS31.0079.B00
SMC Version (system): 1.43b3
LOM Revision: 1.1.2

System Software Overview:

System Version: Mac OS X 10.6.2 (10C540)
Kernel Version: Darwin 10.2.0
Boot Volume: XserveHW_SL
Boot Mode: Normal
Secure Virtual Memory: Not Enabled
64-bit Kernel and Extensions: Yes

gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.


The only differencies are frequency and build of GCC. It could happen that the last hides the cause...

Thanks,
Alexander.

[jaewonj]

Alexander,

You're right. The problem doesn't appear with gcc 4.0. Thanks.

i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.

I'll forward this information to the release engineering team.

Regards,
Jaewon

[Gennady_F_Intel]

another possibleWorkarounds is:Instead of 'gcc' call directly executable 'i686-apple-darwin10-gcc-4.2.1'.

--Gennady

[jaewonj]

Gennady,

i686-apple-darwin10-gcc-4.2.1 also worked. Thanks. Do you have any reference that explains why this is happening?

Jaewon

[Gennady_F_Intel]

Jaewon,

We believe that this looks like problem of linker, which messes static constants.

For example incorrect results from ZGETRF are because constant complex one becomes really complex minus one and that leads to incorrect results.

--Gennady

[jaewonj]

Gennady,

When I initially reported this problem, the MKL version I used was 10.2.3. I found the problem still exists in 10.2.5. Has this problem been resolved in 10.2.6 or 10.3?

Thanks.
Jaewon

[mecej4]

From all the posts in this thread, I gather that this is a problem specific to the Apple OSX platform. And, from what Gennady Fedorov has stated, it is attributable to the OSX linker, which is controlled by Apple, not Intel. On Linux-x64, your example runs fine with the 11.1.073 compiler and MKL 10.2.6.

The solution, it seems, should come from Apple, although Intel has an interest in seeing it emerge.

I do not understand why Apple is dragging its feet with all the XCode problems that we see so much of on this forum, and why Apple users put up with such nonchalance. I admit, however, that I speak as a casual observer -- the last experience I had with any of Jobs' computers was with a NeXT workstation in the early 1990s, and it was fine for the time.

[jaewonj]

Thanks, mecej4. Yes, this issue is Mac specific, and can be reproducible with gcc (4.2.1 build 5664) and icc (11.1 089).

[jaewonj]

No longer reproducible with MKL 10.3. Thanks Gennady for looking into this issue.