New UCRT dependency in Intel FORTRAN 2017?

[Sorensen__Henrik]

We are updating from Intel FORTRAN XE Composer 2015 Update 5 to 2017 Update 1. It is used to build FORTRAN dll's called from C#, all of it built from one and the same solution under VS 2015. Its seems that there is now a dependency from FORTRAN on UCRT (UCRTBASE.DLL via VCRUNTIME140.DLL) which was not there before. Earlier we only depended on MSVCRT120.DLL.

According to descriptions on the internet "The new Universal C Runtime is needed when programmers use the new Windows 10 Software Development Kit to build Universal/Metro apps and you try to run them ...". We have not made any active choice to do that hence do not appreciate why we have the new dependencies.

Our real problem is resolving the run-time when distributing our application carrying the FORTRAN dll's. It seems we either need to distribute a VCRT installer or rely on KB2999226 being present on the target platform.

Can anyone shed some light on this? Is it possible to refrain from relying on the UCRT via some setting in Intel FORTRAN or VS 2015? If not, then what are we to distribute, as part of the normal setup package we use, to roll out our application?

[Xiaoping_D_Intel]

Is there any 3rd-party subroutine called by your fortran code? Intel fortran runtime libraries don't depend on VCRUNTIME140.DLL and UCRT.

Thanks,

Xiaoping Duan

Intel Customer Support

[Sorensen__Henrik]

Hello,

I am afraid I think I have proven that the dependency can exist. Attached is a very simple FORTRAN console application made from scratch using VS 2015. The Intel compiler version is 2017 Update 1. When run on a Win 7 32 bit target machine not having UCRT (missing Windows update KB2999226) it fails with an unresolved dependency as per the attached screen shot. Attached is also a screen shot showing the dependency on VCRUNTIME140.dll.

This seems to be related to VS 2015 using toolset version 14 when building. That appears from the BuildLog.htm in the Relase folder of the FORTRAN solution "/Qlocation,link,&quotC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin&quot".

Is there a way to force the use of another toolkit for the FORTRAN projects? We would like to make use of the versino 12 tolkit as we did with VS 2013. For other reasons using VS 2013 is not a good option for us.

Regards,

Henrik

[Xiaoping_D_Intel]

Sorry that I incorrectly tried VS2013 + ifort to reproduce the problem. Now using VS2015 I can reproduce the dependency on UCRT.

You can remove the dependency by linking static runtime libraries. It is set by "Project Properties -> Fortran -> Libraries -> Runtime Library". The corresponding compiler option is "/MT".

Thanks,

Xiaoping

[Sorensen__Henrik]

Hello,

Thank you for the suggestion. It works in the sense of freeing us from distributing UCRT via VCRedist.

Regards,

Henrik

[Steven_L_Intel1]

The UCRT dependency is from VS2015. It isn't from Intel Fortran. The UCRT DLLs are distributed by Microsoft, as part of Windows 10 but installed separately on older WIndows versions. It doesn't matter if you use any new APIs.

[Sorensen__Henrik]

Hello,

We do recognize that UCRT is introduced by VS2015. However, we still have a problem, no longer with redist, but with differences in results as compared to our previous situation. We were on VS2013 and Intel 2015 Update 5. Now we are on VS2015 and Intel 2017 Update 1.

The problem is that on 2 machines we see differences in results depending on the use of Intel 2015 vs. Intel 2017 runtime. On 2 other machines we do not see these differences, and we have so far been unable to get to the bottom of it. Apparently there is no "important" differences between the machines and they are all Lenovo Thinkpad 4X0 series. They all have VS 2013, VS 2015, Intel 2015 Update 5 and Intel 2017 Update 1 installed.

We have (maybe) managed to isolate the issue to libmmd.dll. I have renamed all the 32 bit versions of libmmd.dll in Program Files (x86) and can force use of version 15 or 17 by renaming back the file in C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler (version 15) or C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler (version 17). I have no local runtime files in the project folders. The results coming out are not very different. We are talking 1E-14 to begin with, but they accumulate to sizable differences due to many many operations in our code.

I have tried to increase the single precision constant precision and setting the FP model to Precise. I get different results than before doing so, but still differences of the same magnitude between Intel 15 and 17 libmmd.dll, which is the actual problem. I run Debug x86 which is normally very conservative (safe) in FP speculation etc.

The scenario I have used to reproduce this is an Intel FORTRAN dll built using 2017 Update 1 called from a simple test.exe program also built using 2017 Update 1. All of it from VS2015 Update 3. I call the dll via DLLIMPORT. The vfproj-files are attached.

The strange thing is that if I put all the code into the test.exe project, i.e. does not make use of a dll, I get the same results using Intel 15 and 17 libmmd.dll. So having some of the code in a dll makes a difference.

I have also tried to build the test.exe from VS2013 and run it. It gives the same results as when running from VS2015. Since Intel 2017 Update 1 is present it anyway builds using that version even from VS2013 so there should not be any difference and I did not go to lengths and built the dll from VS2013 also.

In summary we are at loss of what is going on. Is this in any way a known issue? Any ideas of how to proceed in resolving this? Do you need the actual example or can you supply some "tracking code"? Would it help to be able to remote my machine?

Regards,

Henrik

[Steven_L_Intel1]

I suggest you look through the attached presentation.

443546

[Sorensen__Henrik]

Hello,

I went through the presentation. We already have fp model at precise ref. slides 14 and 15. I also tried out strict but it did not make any difference. I am not able to find the fimf switches mentioned in slide 18. Are they for the FORTRAN compiler?

Anyway I managed to reproduce the problem I see with a purely self-contained FORTRAN solution, i.e. one which does not call a FORTRAN dll from a FORTRAN exe and where nothing but FORTRAN code is involved. I set up two solutions using the same code and ran them in parallel in debug from VS 2015. One had libmmd.dll 2015 update 5 locally and the other one had libmmd.dll 2017 update 1 locally. The remaining run-time is the system default, i.e. probably 2017 Update 1 as it is the last installed FORTRAN compiler and thus default.

This was run on one and the same machine so there should be no differences in architecture etc. Only difference could be in which functions the two versions of Intel runtime invoke.

Monitoring various variables suddenly a small difference appears. It is outlined and highlighted in the attached screen shots. The difference appears with the variable DIFF. DIFF is a difference between two vector elements FGX(I) and FGY(I). The only loop index for which DIFF differs between the two parallel runs is 28. With the Intel version 15 runtime DIFF ends at 280 which corresponds with the difference in numbers. The extra decimal in DIFF not existing on FGX and FGY is assigned a 0. With the Intel version 17 runtime DIFF ends at 283. The extra decimal in DIFF has been assigned 3 instead of 0. This is reproducible from run to run.

In my view the assignment done by runtime 17 is not correct. However, when deducting the numbers directly in code

FGX28 = -80.3634455230168D0
FGY28 = -71.2470484934640D0
DIFF = FGX28 - FGY28

or in Excel, a value of -9.11639702955279 is obtained, i.e. 279 instead of 280 at the end.

I guess what I am missing is a way to enforce the same rounding/result and I am out of ideas. It might be -fp-model = double or something else, but I find we have the safest settings available. Please have a look at the attached vfproj-file to see if anything more could be done.

We need to be able to trust that the same numbers appear across machines etc. even if it is at the expense of performance.

It might be that our code is unfortunate. It is just hard for me to grasp why there should be a difference in results given the setup.I hope you can help.

Regards,

Henrik

[mecej4]

It is not appropriate to state what IEEE arithmetic should and should not do in terms of decimal numbers, because most of the time the decimal-formatted representation is an approximation to the internal binary representation, and vice versa. Since all floating point arithmetic is done with binary numbers, viewing intermediate results in decimal representation is as clear as viewing through frosted lenses.

The two numbers (that you take the difference of) are shown to 15 significant digits. After you take the difference, there are 14 digits left. What you are arguing about (279 vs. 280) concerns a difference of 1 in the 15-th  digit of the difference, which is the same as a difference of 1 in a digit that was not present in the two numbers that you subtracted, i.e., in their 16-th significant digits, which are unknown. In other words, the well known problem of subtractive cancellation occurred.

There may exist a legitimate issue regarding reproducibility; however, the arguments need to be made in a different and more convincing way.

[TimP · Accepted solution]

Besides setting /Qimf-arch-consistency:true if you want math function results which don't vary slightly with the architecture, you would set /assume:protect_parens or /standard-semantics if you want ifort to comply with Fortran rules on parentheses.

/fp:double isn't implemented in ifort.  It's an option to attempt to make ICL work according to K&R mode on certain CPUs.  ifort option /arch:ia32 (for 32-bit mode only) has a similar effect, but if you want expressions involving single precision variables to be promoted to double consistently, you should write it in explicitly, e.g. by REAL(x,REAL64) or DBLE(x).  Likewise, you should write constants like 1.234_REAL64.

[Sorensen__Henrik]

Thanks for all the input. The tip about  /Qimf-arch-consistency:true did the trick.

However, now we have an issue with 32 vs. 64 bit results. It is the same tests cases as gave us problems in the first place. I think we have set all the bells and whistles of relevance as per the attached example vfproj-file but still. I must admit I did not try out /assume:protect_parens yet. Nor have I tried fpconstant.

But I am curious whether consistency across 32 bit to 64 bit is expected and if any particular switches shall be set to get it.

[Steven_L_Intel1]

 No - such consistency is not to be expected. I hope you don't need /fpconstant as that implies incorrect source code. As usual, I suggest instrumenting your code to see where results start to vary.