Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
7234 Discussions

Having problems calling MKL BLAS from VS2005 mixed language project 64bit

Tony_Garratt
Beginner
3,978 Views
I am using VS2005, Intel Fortran 10and MKL 10. I have a VS2005 that has C++ routines that call Fortran routines and those Fortran routines call LAPACK and BLAS routines. Everything works fine in 32bit and I am linking statically (I only need to add mkl_s.lib as a additional library).
When switching to win64, I add the following libraries to the build in VS2005

Solvers.lib mkl_core.lib mkl_intel_lp64.lib mkl_intel_thread.lib libguide.lib

The link suceeds. But when the Fortran calls the BLAS routines (e.g. DGEMV), I immediately geta crash.

So, the question is: how do I statically link to the MKL 64bit libraries from VS2005 please? I have tried several different sets of static libs, but either a link error or when I do link successfully, always crash when calling the BLAS.

Thanks!
Tony
0 Kudos
38 Replies
TimP
Honored Contributor III
1,707 Views
If you use OpenMP (or any threading) in VC, you would require a link with libiomp5. While the documents say libiomp5 supports only VS2008, "it worked for me" with VS2005 also.
0 Kudos
Tony_Garratt
Beginner
1,707 Views
Quoting - tim18
If you use OpenMP (or any threading) in VC, you would require a link with libiomp5. While the documents say libiomp5 supports only VS2008, "it worked for me" with VS2005 also.

Many thanks Tim for your suggestion. I gave it a try, but Im still getting the crash.
0 Kudos
Gennady_F_Intel
Moderator
1,707 Views
Tony,
You dont need to use solver libs for linking BLAS functionality on Win64 system
1.The recommended libraries are: mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib
2. Please attention you have to use libraries from < MKLROOT>em64t directory.
--Gennady

0 Kudos
Tony_Garratt
Beginner
1,707 Views
Tony,
You dont need to use solver libs for linking BLAS functionality on Win64 system
1.The recommended libraries are: mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib
2. Please attention you have to use libraries from < MKLROOT>em64t directory.
--Gennady


Thank you. I followed your instructions and rebuilt. When running the project, VS2005 complained that it could not find libiomp5md.dll, so I added the location of em64t/bin to the path, restarted VS2005 and rebuilt the project. And it crashed again in dgemm. What is odd is that it works fine for win32 builds.
0 Kudos
Gennady_F_Intel
Moderator
1,707 Views

Tony,
Can you get the example of your code? I will try to investigate the problem.
--Gennady

0 Kudos
Tony_Garratt
Beginner
1,707 Views

Tony,
Can you get the example of your code? I will try to investigate the problem.
--Gennady


The project has a lot of propretiary code in it, so it would be difficult to pass it on to you. However, I am upgrading to MKL 10.1 and will try again - if I still get problems, Ill put together a smaller test case that reproduces it.
0 Kudos
Gennady_F_Intel
Moderator
1,707 Views
Hello Tony, is the problem is still there? Gennady

0 Kudos
sudhir_singh
Beginner
1,707 Views
Hi Tony, Tim and Gennady,

I have the exactly same problem as Tony.

We used MKL 7.0 with Intel Fortran Compiler 9.1 & 10.0.027 for a VS2003 win32 C++executableand used to link against mkl_s_dll.lib in our source code. The calls to blas routines like DGEMVfor all MKL 7.0 dlls used to run absolutely fine.

Then we had to create a 64 bit version of this executable. So we decided to use VS2005 for win64 platform along with MKL 10.1 and Intel Fortran Compiler 10.1. For this we choseto link with mkl_core_dll.lib, mkl_intel_lp64_dll.lib and mkl_intel_thread_dll.lib in em64tlib folder. While the build was successful,during runtime despite all MKL 10.1 dlls being in path the executable would crash while calling DGEMV routine. I have verified that all arguments passed to the routine are good.

I have also tried linking against other combinations including:
1. mkl_core_dll.lib, mkl_intel_lp64_dll.lib, mkl_intel_thread_dll.lib
2. Statically linking against mkl_core.lib, mkl_intel_lp64.lib, mkl_intel_thread.lib
3. mkl_core_dll.lib, mkl_intel_ilp64_dll.lib, mkl_intel_thread_dll.lib
4. Statically linking against mkl_core.lib, mkl_intel_ilp64.lib, mkl_intel_thread.lib
5. mkl_core_dll.lib, mkl_intel_lp64_dll.lib,mkl_intel_thread_dll.lib, libiomp5md.lib
6. mkl_core_dll.lib, mkl_intel_ilp64_dll.lib, mkl_intel_thread_dll.lib, libiomp5md.lib
7. mkl_dll.lib along with referenced libraries
8. mkl_em64t.lib along with referenced libraries

All of them would reproduce the problem.

Also I have the followingobservations w.r.t. MKL library versions:
Fortran 10.1 + MKL 10.1 crashes
Fortran 9.0 + MKL 10.1 crashes
Fortran 9.0 + MKL 7.0 works
Fortran 10.1 + MKL 7.0 works

I'll be grateful if you guys can help mefind what can be going wrong. The crash occurs while calling DGEMV in the subroutine below.

SUBROUTINE MA50GD(M,N,A,LDA,NB,PIVTOL,IPIV,RANK)

INTEGER LDA,M,N,NB,RANK
DOUBLE PRECISION PIVTOL

INTEGER IPIV(N)
DOUBLE PRECISION A(LDA,N)

DOUBLE PRECISION ONE,ZERO
PARAMETER (ONE=1.0D+0,ZERO=0.0D+0)

INTEGER I,J,JJ,JP,J1,J2,K
LOGICAL PIVOT
DOUBLE PRECISION TEMP

EXTERNAL DGEMM,DGEMV,DSWAP,DSCAL,DTRSM,DTRSV

INTEGER IDAMAX
EXTERNAL IDAMAX

INTRINSIC ABS,MIN

J = 1
J1 = 1
J2 = MIN(N,NB)
DO 70 K = 1,N

IF (J.LE.M) THEN

CALL DGEMV('N',M-J+1,J-J1,-ONE,A(J,J1),LDA,A(J1,J),1,ONE,A(J,J),1)
.................................................................
.................................................................

0 Kudos
Gennady_F_Intel
Moderator
1,707 Views
As an example, I have uploaded to this thread DGEMV.zip file contains
VS2005 based Fortran project is linked with mkl 10.1 with X64 mode.
See more details in Project properties settings.
You can adjust these settings and try to run the project.

The expected output:
----------------------------------------------------
D G E M V EXAMPLE PROGRAM

INPUT DATA
M=4 N=5
ALPHA= 0.56 BETA= 1.00
TRANS=T
VECTOR X INCX=-1
1.000 2.000 3.000 4.000
VECTOR Y INCY= 1
1.000 1.000 1.000 1.000 1.000
ARRAY A LDA=4
-1.300 2.300 3.700 4.300 5.900
-1.800 2.800 3.200 4.600 5.700
1.100 2.200 3.000 4.500 5.400
1.900 2.800 3.400 4.200 5.100

OUTPUT DATA
VECTOR Y INCY= 1
-2.640 14.888 19.928 25.752 32.696
Press any key to continue . . .
---------------------------------------------------
I hope it will help you.
--Gennady

0 Kudos
TimP
Honored Contributor III
1,707 Views
DGEMV doesn't handle the combination M>0 N==0 correctly. My understanding is MKL is designed to be bug compatible with the netlib version. The comments in the netlib reference source imply that it should work, but that's inconsistent with the source code. I don't think this has been discussed since this forum started.
0 Kudos
Tony_Garratt
Beginner
1,707 Views
Hello Tony, is the problem is still there? Gennady


Yes - it is still there. It must be a real problem because two others have reported issues too.
0 Kudos
Tony_Garratt
Beginner
1,707 Views
Quoting - sudhir.singh
Hi Tony, Tim and Gennady,

I have the exactly same problem as Tony.

We used MKL 7.0 with Intel Fortran Compiler 9.1 & 10.0.027 for a VS2003 win32 C++executableand used to link against mkl_s_dll.lib in our source code. The calls to blas routines like DGEMVfor all MKL 7.0 dlls used to run absolutely fine.

Then we had to create a 64 bit version of this executable. So we decided to use VS2005 for win64 platform along with MKL 10.1 and Intel Fortran Compiler 10.1. For this we choseto link with mkl_core_dll.lib, mkl_intel_lp64_dll.lib and mkl_intel_thread_dll.lib in em64tlib folder. While the build was successful,during runtime despite all MKL 10.1 dlls being in path the executable would crash while calling DGEMV routine. I have verified that all arguments passed to the routine are good.

I have also tried linking against other combinations including:
1. mkl_core_dll.lib, mkl_intel_lp64_dll.lib, mkl_intel_thread_dll.lib
2. Statically linking against mkl_core.lib, mkl_intel_lp64.lib, mkl_intel_thread.lib
3. mkl_core_dll.lib, mkl_intel_ilp64_dll.lib, mkl_intel_thread_dll.lib
4. Statically linking against mkl_core.lib, mkl_intel_ilp64.lib, mkl_intel_thread.lib
5. mkl_core_dll.lib, mkl_intel_lp64_dll.lib,mkl_intel_thread_dll.lib, libiomp5md.lib
6. mkl_core_dll.lib, mkl_intel_ilp64_dll.lib, mkl_intel_thread_dll.lib, libiomp5md.lib
7. mkl_dll.lib along with referenced libraries
8. mkl_em64t.lib along with referenced libraries

All of them would reproduce the problem.

Also I have the followingobservations w.r.t. MKL library versions:
Fortran 10.1 + MKL 10.1 crashes
Fortran 9.0 + MKL 10.1 crashes
Fortran 9.0 + MKL 7.0 works
Fortran 10.1 + MKL 7.0 works

I'll be grateful if you guys can help mefind what can be going wrong. The crash occurs while calling DGEMV in the subroutine below.

SUBROUTINE MA50GD(M,N,A,LDA,NB,PIVTOL,IPIV,RANK)

INTEGER LDA,M,N,NB,RANK
DOUBLE PRECISION PIVTOL

INTEGER IPIV(N)
DOUBLE PRECISION A(LDA,N)

DOUBLE PRECISION ONE,ZERO
PARAMETER (ONE=1.0D+0,ZERO=0.0D+0)

INTEGER I,J,JJ,JP,J1,J2,K
LOGICAL PIVOT
DOUBLE PRECISION TEMP

EXTERNAL DGEMM,DGEMV,DSWAP,DSCAL,DTRSM,DTRSV

INTEGER IDAMAX
EXTERNAL IDAMAX

INTRINSIC ABS,MIN

J = 1
J1 = 1
J2 = MIN(N,NB)
DO 70 K = 1,N

IF (J.LE.M) THEN

CALL DGEMV('N',M-J+1,J-J1,-ONE,A(J,J1),LDA,A(J1,J),1,ONE,A(J,J),1)
.................................................................
.................................................................


Hi,
I took your project and loaded into VS2005+Intel Fortran 10+MKL 10.1. There was a message about re-integration in VS required. After changing the lib path to my MKL installation, when running I get an error because libiomp5md.dll cannot be found. Any suggestions? Should MKL be on my path?

thanks
Tony
0 Kudos
Gennady_F_Intel
Moderator
1,707 Views
Yes. See more details in userguide ( Configuring Intel Visual Fortran to Link with Intel MKL)

0 Kudos
sudhir_singh
Beginner
1,707 Views
As an example, I have uploaded to this thread DGEMV.zip file contains
VS2005 based Fortran project is linked with mkl 10.1 with X64 mode.
See more details in Project properties settings.
You can adjust these settings and try to run the project.

The expected output:
----------------------------------------------------
D G E M V EXAMPLE PROGRAM

INPUT DATA
M=4 N=5
ALPHA= 0.56 BETA= 1.00
TRANS=T
VECTOR X INCX=-1
1.000 2.000 3.000 4.000
VECTOR Y INCY= 1
1.000 1.000 1.000 1.000 1.000
ARRAY A LDA=4
-1.300 2.300 3.700 4.300 5.900
-1.800 2.800 3.200 4.600 5.700
1.100 2.200 3.000 4.500 5.400
1.900 2.800 3.400 4.200 5.100

OUTPUT DATA
VECTOR Y INCY= 1
-2.640 14.888 19.928 25.752 32.696
Press any key to continue . . .
---------------------------------------------------
I hope it will help you.
--Gennady


Thanks for the help Gennady. I still cannot resolve the problem at my end. I used the data in my problem with your code and it worked fine. I'll try the same by creating a library with your code and calling it with a C++ executable.
As I am on leave for tommorow, I'll get back in next 2 days on the results.

My data also has the combination combination M=2 and N=0.
0 Kudos
sudhir_singh
Beginner
1,707 Views
Hi,
I took your project and loaded into VS2005+Intel Fortran 10+MKL 10.1. There was a message about re-integration in VS required. After changing the lib path to my MKL installation, when running I get an error because libiomp5md.dll cannot be found. Any suggestions? Should MKL be on my path?

thanks
Tony

Either this dll should becopied tothe same directory as the executable, you can add the mkl10.1em64tbin folder to system path to fix this problem.
0 Kudos
TimP
Honored Contributor III
1,707 Views
Quoting - sudhir.singh

My data also has the combination combination M=2 and N=0.
If you are hitting the bug for N==0, you must catch that case in your own code and avoid ?gemv, or get a copy of the reference source code, fix it there, and not use the MKL version. The reference source is, yes, a valuable reference. You could build with it and step through in a debugger, for example, to see if your usage does expose a bug. Or just step in your own code and see if ?gemv breaks on that case.

0 Kudos
Gennady_F_Intel
Moderator
1,707 Views
One remark:
DGEMV doesn't handle the combination M>0 N==0 correctly.
Its not completely correct.
See mkls description:
call dgemv(trans, m, n, alpha, a, lda, x, incx, beta, y, incy)
m - INTEGER. Specifies the number of rows of the matrix A. The value of m must be at least zero.
n - INTEGER. Specifies the number of columns of the matrix A. The value of n must be at least zero.
Thats mean if N == 0 this the valid calling for dgemv and we are not expectingcrash when calling the BLAS
with N == 0
--Gennady




0 Kudos
Tony_Garratt
Beginner
1,707 Views
One remark:
DGEMV doesn't handle the combination M>0 N==0 correctly.
Its not completely correct.
See mkls description:
call dgemv(trans, m, n, alpha, a, lda, x, incx, beta, y, incy)
m - INTEGER. Specifies the number of rows of the matrix A. The value of m must be at least zero.
n - INTEGER. Specifies the number of columns of the matrix A. The value of n must be at least zero.
Thats mean if N == 0 this the valid calling for dgemv and we are not expectingcrash when calling the BLAS
with N == 0
--Gennady





***This is an MKL BUG*** and need to be fixed by Intel ASAP. The code that sudhir.singh is using is one that I recognise - its a well respected linear solver from the Harwell Subroutine Library (HSL) that is calling BLAS routines. Since the linear solver code will be considered"third party" to most users of HSL, they donot want to be making changes to it to get around a bug in DGEMV because you end up diverging from the HSL source code.
0 Kudos
Gennady_F_Intel
Moderator
1,707 Views

Really? On my side all works fine. Can you get the testcase for reproducing the problem?
0 Kudos
Tony_Garratt
Beginner
1,657 Views

Really? On my side all works fine. Can you get the testcase for reproducing the problem?

I will see if can extract a portion of the code that will reproduce it as I cant give you the whole project. I reason I am so confident its a bug is because my code works fine when compiled as 32bit; crashes when compiled as 64bit.
0 Kudos
Reply