Intel/VS2015 access violation in mixed language program compiled with default -MT switch

[Mick_Pont]

I have a small main program written in Fortran (attached file main.f90) and it calls a simple function written in C (attached file myprintf.c). The C function just calls printf to output the value of its double precision argument (which is passed by reference as dictated by Fortran).

I compile and link the two files like this:

  icl -MT -c myprintf.c
  ifort -MT main.f90 myprintf.obj

When I run the program, it crashes with an access violation inside a Microsoft C run-time library print function (I can see where it is using the Visual Studio debugger)

However, if I compile the files using the -MD switch, like this:

  icl -MD -c myprintf.c
  ifort -MD main.f90 myprintf.obj

then there is no problem - the program runs and prints the expected results. Note that icl and ifort use -MT switches by default so if I omit them althoghether I still get the crash. Something else - if I remove the call of ieee_is_nan() from main.f90, the problem also goes away.

I'm using ifort and icl initialized by a call of

  ifortvars.bat intel64 vs2015

- in other words, telling the Intel compilers to interoperate with the latest Microsoft C. If I use an older version of Microsoft C instead, such as vs2013, then the problem goes away. So - I imagine that the issue is to do with the well-known refactoring of the Microsoft run-time libraries in VS2015.

But - I'm using the latest versions of Intel and Microsoft compilers, which I thought were intended to work properly together. Here are my compiler versions:

  Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.207 Build 20160415
  Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.207 Build 20160415
  Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64

So - am I doing something wrong? Or are the compilers? Or what?

I'd like to get this to work - this test program is cut down from a large amount of code. I work for a company making software libraries and many of our customers require the ability to link statically to libraries built with the -MT switch.

Mick

[TimP]

Reproduced here (with VS2015.3).

So it seems that writing to stdout in C is failing, when called from Fortran, with the VS2015 libraries.

-MT is no longer the default, but it didn't seem to be needed to provoke the failure.

[Kevin_D_Intel]

Thank you for reporting this access violation. I also reproduced this using PSXE 2016 Update 2 (ifort Version 16.0.2.180 Build 20160204) with VS 2015 (Version 14.0.23107.0 D14REL), and confirmed the exception does not occur with the PSXE 2016 Update 2 and VS 2013.

I escalated this to our RTL team for further diagnosis and will let you know what I hear from them.

I do not have VS 2015 Update 3 available but did include Tim’s details in the internal report.

(Internal tracking id: DPD200412661)

[Mick_Pont]

Thanks for escalating Kevin.

Note that the problem is not directly to do with stdout, it's actually crashing in binary-decimal conversion - using sprintf instead of printf shows the same problem.

Also, despite what Tim thought, I think -MT *is* the compiler default - the output of ifort /? says so, and also compiling with -MD avoids the problem.

[Kevin_D_Intel · Accepted solution]

The developers identified the root cause and we expect to have a fix in our next PSXE 2016 Update 4 release (mid-August timeframe).

They found the use of ieee_c_exceptions leads to using Intel’s fegetenv, and that the most recent VS2015 now calls fegetenv() when processing formats %f or %d. However, MS expects their own version of fegetenv, which differs from Intel’s. Since the size of the fenv_t object used by fegetenv() is different in our and MS’s libraries, it causes the segmentation fault.

[Mick_Pont]

Brill - thanks - I look forward to the fixed version

Mick

[Mick_Pont]

I've just tried the latest released compiler version

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.0.109 Build 20160721

and I see the problem is stil there. Do you know if a fix is still on the TO-DO list?

Mick

(EDIT - I now see that the build date of the compiler I just tried is a few days before your last post, so I shouldn't have expected the fix in this version - sorry)

[Kevin_D_Intel]

I haven't confirmed the fix yet myself; however, according to the updates in the internal tracking record the fix was checked into both the 16.0 and 17.0 branches which means it is anticipated in the next PSXE 2016 Update 4 (tentatively due out in a couple of weeks) and the PSXE 2017 Update 1 in the mid-Q4 timeframe. I'll try confirming the fix in the PSXE 2016 Update 4 package and let you know.

[Mick_Pont]

I've just installed and tested Version "16.0.4.246 Build 20160811" and confirm that the problem seems to have been resolved - thanks!

Mick

[Kevin_D_Intel]

Great, glad to hear it!

Unfortunately my Update 4 installation failed so I'm troubleshooting/repairing that rather than confirming fixes. :-(