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

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

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

39 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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.

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.

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

Quoting - Gennady Fedorov (Intel)

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.

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

Quoting - Gennady Fedorov (Intel)

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.

Hello Tony, is the problem is still there? Gennady

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

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

Attachments: 

AttachmentSize
Download DGEMV.zip2.54 MB

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.

Quoting - Gennady Fedorov (Intel)

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.

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

Yes. See more details in userguide ( Configuring Intel Visual Fortran to Link with Intel MKL)

Quoting - Gennady Fedorov (Intel)

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.

Quoting - tgarratt@reactiondesign.com

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.

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.

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

Quoting - Gennady Fedorov (Intel)

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.

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

Quoting - Gennady Fedorov (Intel)

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.

Quoting - Tony Garratt

Quoting - Gennady Fedorov (Intel)

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.

I have been communicating with someone else from another company who has been experiencing the same issues. Basically we believecomes down to getting the crash depending on what libraries you pull in at runtime. To get the crash, I believe you have to (1) Have a mixed C++/Fortran VC2005 project (2) be compiling 64 bit (3) linking against the static MKL libraries. If go back to 32bit or single Fortran project, everything is OK.

I have a get-around for now for this problem, so its not so critical to me that it gets fixed.

Quoting - Gennady Fedorov (Intel)

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.

I hope it will help you.
--Gennady

Gennady, Tony and Tim,

I have successfully reproduced theDGEMV problem in our solver with a much smaller system.

The smaller system that reproduces the problem is uploaded in a zip file along with this post.

The steps to reproduce the problem are the following:
1. First copy the Input.txt file that has data from our problem in the D: drive as the location is hard coded in the problem code.
2. Then set proper paths for all MKL 7.0 and MKL 10.1 libraries that have been linked in all the 3 projects (dgemv, CppExe and FortranLib).
3. Then add the bin directories for MKL 7.0 (IA32) and MKL 10.1 (EM64T) in path so that the dlls can be found at runtime.
4. Project dgemv is the FORTRAN exe project send by Gennady and modified to use the data from Input.txt which resembles the data from our problem. As stated by Gennady, this executable runs fine on both 32 bit and 64 bit.
5. I created a FORTRAN library based on Gennadys source code in the project FortranLib. This library has a FWRAP function that is called by as c++ exe and that in turn calls a FFCN subroutine that will call DGEMV with the data from same Input.txt file. This sequence of function was chosen to resemble the system that we have in our Solver Project.
6. After building the FortranLib project, build the CppExe project which is the c++ exe that statically links to FortranLib library and calls FWRAP function.
7. On running you would find that while 32 bit CppExe.exe runs fine, the 64 bit crashes with the given error.

The basic Idea is that when a 32 bit or 64 bit FORTRAN executable calls DGEMV, it runs fine. Also when a 32 bit c++ exe calls a 32 bit FORTRAN Library that calls DGEMV it works fine. However when a 64 bit c++ exe calls a 64 bit FORTRAN Library that calls DGEMV it crashes even with the same data as the previous cases. The error for the crash is given below. For my test case based on availability, I used MKL 7.0 for 32 bit linking and MKL 10.1 for 64 bit linking in this example that I have posted.

Error when calling DGEMV on my smaller project with same data:
Unhandled exception at 0x000000014000de34 in CppExe.exe: 0xC0000005: Access violation reading location 0x0000000000000001.

Error when calling DGEMV on our Solver Project:
Unexpected exception at code address 0000000140326834: The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Invalid read access at memory address 0000000000000001.

So this seems more like a bug in MKL 10.1 (EM64T). Even if this is not the bug, since it reproduces our problem if Intel can find out how we can fix this executable, well be able to get our solver project working.

I'll like to thank each of you for your support.

Thanks sudhir for reproducing it and sending it to Intel. You are seeing exactly what I have been experiencing too.

Sudhir,
before reproducing the problem, could you please tell me, what was the reason to use two completely different MKL's versions into one project. Or I missed something?Could you please remove all 7.0 dependencies and try to catch the problem again.
--Gennady

Quoting - Gennady Fedorov (Intel)

Sudhir,
before reproducing the problem, could you please tell me, what was the reason to use two completely different MKL's versions into one project. Or I missed something?Could you please remove all 7.0 dependencies and try to catch the problem again.
--Gennady

Gennady,

I used 2 different MKL versions because our 32 bit solver project currently uses MKL 7.0 and we are migrating it to 64 bit where we are trying to use MKL 10.1. So these 2 versions will provide the exact case that we have.
However I have changed the same application to use MKL 10.1 for both 32 bit and 64 bit and this still reproduces the crash with 64 bit while running fine with 32 bit. The new application is attached with this post.

Regards,
Sudhir Kumar Singh

Attachments: 

AttachmentSize
Download DGEMV.zip2.54 MB

null

Hi Gennady,

I have not heard from you on this problem since I provided the sample code to reproduce it.

We (Invensys)have a support contract with Intel and would like you to state whether we should seek any other channel for getting support on this problem. This crash has become critical to our Project. You can contact me directly at Sudhir.Singh@ips.invensys.com for any further information.

Hope to hear from you soon.

Regards,

Sudhir Kumar Singh

Finally I myselffixed the DGEMV crash that was blocking us in our 64 bit solver project. The fix was mainly due to a build option regarding External Procedures in the Fortran Library Project.

We had previous been using String Length Argument Passing options as After Individual String Argument. This used to work fine with MKL7.0 and MKL10.1 IA32 (32 bit) libraries. However with MKL 10.1 EM64T (64 bit) libraries, it caused a crash.

Changing this option to After All Arguments (/iface:nomixed_str_len_arg) fixed the crash. No change was needed in C++ project.

This option specifies the type of argument passing convention used for general arguments and for hidden length character arguments.

MKL should be supporting both these conventions for both 32 bit and 64 bit executables. So this crash can be because of something wrong eitherin MKL or in Intel Fortran Compiler. I hope this workaround can help otherswho seethis problem and so have posted it here.

The :nomixed_str_len_arg was well established as the only method in use for 64-bit systems, well before IA 64-bit systems came about. It can hardly be described as a work-around. When you are interested in portable software, you follow the standards, which include now the Fortran iso_c_binding; you don't ask for implementation of an option which has been in disuse by consensus for 8 years. If you don't get a compile time diagnosis when attempting a bad option in 64-bit ifort, that would be a good subject for a formal problem report.

Quoting - tim18
The :nomixed_str_len_arg was well established as the only method in use for 64-bit systems, well before IA 64-bit systems came about. It can hardly be described as a work-around. When you are interested in portable software, you follow the standards, which include now the Fortran iso_c_binding; you don't ask for implementation of an option which has been in disuse by consensus for 8 years. If you don't get a compile time diagnosis when attempting a bad option in 64-bit ifort, that would be a good subject for a formal problem report.

Hang on a bit Tim please. You have to remember that many users of MKL may be more mathematics skilled people, may not be expert programmers andmay notfully understand some of the implications of these standards. I was stuck with this issue too. My background is mathematics - Im not an expert programmer, but Im not dumb either and it got me stumped too. It seems both Singh and I were got by the default external procedures option - seems obvious now of course, but the obvious gets past the best of us.

What would have helped us here? I think better documentation of MKL (improving the documentation is a theme I keep banging on about to Intel) could have done it here, or an FAQ of "common build errors". I know it so easy to blame bad documentation, but Intel dont seem to understand that the user base of MKL may not be expert programmers and more maths related folk- they are wanting to use MKL to get better performance on theirnumerical codes, so by definition are likely to be more maths/numerical skilled than programming. Just a little bit more "hand holding" in the documentation for MKLcould go a long way and making sure this hand holding is right up there in a Getting Started Guide for instance. I know it would have helped usavoid several pot-holes with MKL along the way that cost us man hours that could so easily be avoided.

p.s. I see that the 10.1 documentation is much better than 10.0 - thank you Intel. But I would like to venture there is still more to do. Just taking common errors from this forum and posting up an FAQ on the web would be a start, sort of "go here first if you have problems before posting on the forum or submitting a premier ticket"

Quoting - Tony Garratt

Hang on a bit Tim please. You have to remember that many users of MKL may be more mathematics skilled people, may not be expert programmers andmay notfully understand some of the implications of these standards. I was stuck with this issue too. My background is mathematics - Im not an expert programmer, but Im not dumb either and it got me stumped too. It seems both Singh and I were got by the default external procedures option - seems obvious now of course, but the obvious gets past the best of us.

What would have helped us here? I think better documentation of MKL (improving the documentation is a theme I keep banging on about to Intel) could have done it here, or an FAQ of "common build errors". I know it so easy to blame bad documentation, but Intel dont seem to understand that the user base of MKL may not be expert programmers and more maths related folk- they are wanting to use MKL to get better performance on theirnumerical codes, so by definition are likely to be more maths/numerical skilled than programming. Just a little bit more "hand holding" in the documentation for MKLcould go a long way and making sure this hand holding is right up there in a Getting Started Guide for instance. I know it would have helped usavoid several pot-holes with MKL along the way that cost us man hours that could so easily be avoided.

p.s. I see that the 10.1 documentation is much better than 10.0 - thank you Intel. But I would like to venture there is still more to do. Just taking common errors from this forum and posting up an FAQ on the web would be a start, sort of "go here first if you have problems before posting on the forum or submitting a premier ticket"

Changing to After All Arguments (/iface:nomixed_str_len_arg) fixed my crashes too. I think the action item for Intel is to consider making this the default for 64bit Fortran projects in dev studio, if the current default is to be discouraged.

I need to agree with Tim, it's hard to call a workaround. It's just fixing the code/interfaces to external routines. However, my quick check shows, that linker doesn't detect it (can it?) at least with pure BLAS calls (I didn't check 95 interfaces). Am I right?

All that leads to Tony and Sudhir's problems and "hard way" porting to x64 platform. Tony is obviously right that MKL docs need some clearer, better elaboration in many parts (I have myself couple of Premier Support issues on that). The IVF compiler docs state that C interface is provided for x64, ONLY, while MKL says that for C the lenght is passed after (but explains it for IA32 platform). So it's not entirely clear how it goes with x64.

Tony is also right that MANY people using MKL come from more math/numerics that programming "world". If Intel wants to expand the usage of MKL there, need to address issues of "after installation" settings, adjusting etc. I remember it took once 15 posts to help somebody to set up it in VS on Vista.

On the other hand, if somebody uses non-default setting(s) (mixed_str_len_arg in this case) should know what he's doing or accept defaults:-)

A.

Quoting - Tony Garratt

Changing to After All Arguments (/iface:nomixed_str_len_arg) fixed my crashes too. I think the action item for Intel is to consider making this the default for 64bit Fortran projects in dev studio, if the current default is to be discouraged.

Tony,

nomixed_str_len_arg is default in VS. You probably extracted your project from CVF (IA32 platform), where STDCALL was default and mixed_str_len_arg. Then adding mkl_s.lib made your transition to IVF smooth, but further to x64 a "bit" more difficult.

A.

Quoting - ArturGuzik

Tony,

nomixed_str_len_arg is default in VS. You probably extracted your project from CVF (IA32 platform), where STDCALL was default and mixed_str_len_arg. Then adding mkl_s.lib made your transition to IVF smooth, but further to x64 a "bit" more difficult.

A.

Aghhhh! Yes! You are absolutely correct - I started from a win32 project and created an x64 one from that. That explains it! Thank you!

Quoting - tim18
The :nomixed_str_len_arg was well established as the only method in use for 64-bit systems, well before IA 64-bit systems came about. It can hardly be described as a work-around. When you are interested in portable software, you follow the standards, which include now the Fortran iso_c_binding; you don't ask for implementation of an option which has been in disuse by consensus for 8 years. If you don't get a compile time diagnosis when attempting a bad option in 64-bit ifort, that would be a good subject for a formal problem report.

Well may be it is not a work around. The compiler compiles fine with a wrong configuration and then it crashes at runtime. Should this wrong configuration option be available tointel compiler with 64 bit configuration? Even if it is available, should it not signal errors during compilation. May be thisbehaviour is a bug.
If Mr Tim was so smart to know about all establishedstandards he should have taken a look at the project I posted and could have got back on the way it could be fixed :D
But seems like that was so easy to miss and so difficult to find. So it was there for more than one week, and no one touched it.
In allsince I did not get any support from intel regarding this, and since this entire thread seems to say that its users fault when they get problems,Isuggest removing this thread and let all other users figure out themselves why their ported 32 bit projects won't run when build for x64 machines.
I am not a Fortran developer, I work mainly in C++ and since all Fortran developers in my company couldNOT figure our why this failed, I had to look into it and I did fix it.
Intel needs to do better on supporting its software, may be better involvement in the forums will help.
Now ifanyone isremoving this post for blunt feedback in name of abuse or violation of T&C, please consider removing the entire thread or atleast all my posts in this thread.

Quoting - sudhir.singh

Well may be it is not a work around. The compiler compiles fine with a wrong configuration and then it crashes at runtime. Should this wrong configuration option be available tointel compiler with 64 bit configuration? Even if it is available, should it not signal errors during compilation. May be thisbehaviour is a bug.
If Mr Tim was so smart to know about all establishedstandards he should have taken a look at the project I posted and could have got back on the way it could be fixed :D
But seems like that was so easy to miss and so difficult to find. So it was there for more than one week, and no one touched it.
In allsince I did not get any support from intel regarding this, and since this entire thread seems to say that its users fault when they get problems,Isuggest removing this thread and let all other users figure out themselves why their ported 32 bit projects won't run when build for x64 machines.
I am not a Fortran developer, I work mainly in C++ and since all Fortran developers in my company couldNOT figure our why this failed, I had to look into it and I did fix it.
Intel needs to do better on supporting its software, may be better involvement in the forums will help.
Now ifanyone isremoving this post for blunt feedback in name of abuse or violation of T&C, please consider removing the entire thread or atleast all my posts in this thread.

Hi Sudhir.

Tim did come on a bit strong with his point about standards, but pleaselets not delete this thread because it is very valuable to others. Both you and I got hit by this one and it took a lot of time to get to the bottom of it. In the end you solved it for me (thank you!!!!), as I gave up and had to go down a getaround path - all of which costed time and money.

Intel - please get the lessons learned from this one into the documentation someplace as an FAQ. Its a subtle one that caught Sudhir and I out (and at lease one other person who contacted me directly via the forum).

Sudhir brings up a point - should he have gone the premier support issue path for this problem or the forum? Is the purpose of the forum to give support to users of MKL or are they better off submitting a premier support ticket?

Quoting - Tony Garratt
Sudhir brings up a point - should he have gone the premier support issue path for this problem or the forum? Is the purpose of the forum to give support to users of MKL or are they better off submitting a premier support ticket?

Hi,

I sumbitted support issue on that (clarifying docs and detecting misconfig) and it's not detected by linker. Will see if this helps.

The part of the problem, as Tim said, is that you both used non-standard, and non-default (!!!) in VS setting, instead of setting it up, just copying/extracting from IA32, most probably CVF, STDCALL interface type version (your code was portable, but your project not). I'm not sure it possible to remove the setting in VS (for x64). Please keep in mind that it's integration in VS, and many things cannot be done, as guys at MS change internal interfaces all the time (that's why, as far as I know, there is no source browser etc.). On the other hand I really understand the frustration. One week is a long time. Speed of Premier Support is a different story.

A.

In my initial response, I pointed out that the 64-bit compiler should complain about the use of an argument passing convention which is unlikely to work. As the story came out that automatic conversion from a CVF project, followed by invocation of 64-bit compiler, is a likely way for this to come about, it's more important, IMO, that warnings should be issued at more than one step about attempting to carry over the old CVF convention. So, this exchange should have a useful value.

Quoting - tim18
In my initial response, I pointed out that the 64-bit compiler should complain about the use of an argument passing convention which is unlikely to work. As the story came out that automatic conversion from a CVF project, followed by invocation of 64-bit compiler, is a likely way for this to come about, it's more important, IMO, that warnings should be issued at more than one step about attempting to carry over the old CVF convention. So, this exchange should have a useful value.

I received e-mail this morning about a compiler problem report filed to address this issue. So it is agreed that the compiler should provide better guidance on the option choice.

Leave a Comment

Please sign in to add a comment. Not a member? Join today