topic Interesting finding. I see in Intel® Fortran Compiler

Problem with setting Intel Compiler Setting in Visual Studio 2013

Sorensen__Henrik — Fri, 13 Jan 2017 14:57:31 GMT

Hello,

After installing Intel 2017 Update 1 on machines having Visual Studio 2013 and 2015 and Intel 2015 Update 5, some of our FORTRAN projects give error 8110 while linking, but only in 32 bit configuration. We have tracked down that the setting for Executables under Tools -> Options -> Intel Compilers and Tools -> Visual Fortran -> Compilers have an influence. Before installing Intel 2017 Update 1 and VS 2015, the setting for Executables on the Win32 tab had ia32 in it. After installing Intel 2017 Update 1 and VS 2015 in has Intel64 in it. However, under Libraries it still says ia32_win.

If we change the setting to contain ia32 rather than Intel 64 the problem goes away. Actually after doing so we cannot make the setting stay at Intel64. It flips back to ia32 after each restart of VS2013.

However, it is suspicious that it says Intel64 on the Win32 tab under executables (and not under Libraries). In VS2015 it also says Intel64 in the same place sp VS2015 and 2013 look the same in that respect.

Is it a bug that it says Intel64 in the Win32 tab in VS2013, or even in VS2015 after installation of Intel 2017 Update 1?

Is the correct setting ia32 or Intel 64? We all have 64 bit Windows installed, primarily Windows 7 SP 1 with full Windows Updates.

Apart from the issue with the setting, any hint to the actual error 8110? It is a linker error saying that what it tries to link to was compiled for a different platform or by an incompatible compiler release. We did full Clean Solution to make sure no old stuff is hanging.

I hope someone can help or guide.

Regards,

Henrik

Hello again,

Sorensen__Henrik — Fri, 13 Jan 2017 15:26:08 GMT

Hello again,

It turns out we are using post-build events like this one

It is the projects linking to the obj-files generated using such post-build events which show the error 8110.

Is the post-build event somehow wrong in relation to the Intel64 setting/Intel 2017 Update 1, or is there some bug?

Actually right now I am more concerned with the value and behavior of the setting itself (ia32 or Intel64) in Visual Studio.

Regards,

Henrik

Interesting finding. I see

Kevin_D_Intel — Fri, 13 Jan 2017 17:13:00 GMT

Interesting finding. I see what you described on one system but not another. I reported this to our integration developers.

I'm not following the post-build event. That appears to be a compile/link command-line. Does that appear under the Build Events > Post-Build Event > Command Line setting of your Fortran project?

(Internal tracking id: DPD200417041)

Hello,

Sorensen__Henrik — Mon, 16 Jan 2017 07:34:02 GMT

Hello,

Thanks for the response.

Yes, the post build event appears under the Build Events > Post-Build Event > Command Line setting of the Fortran project. It is a trick we had to play due to duplicate definitions of routines (bad code organization from our side). We have reorganized our way out of it code-wise so the problem is not there in our newest versions. However, we are pursuing the problem for two reasons

1. In case we need to make a hotfix for the old code-base.

2. To understand what is the correct setting for Executables under Tools -> Options -> Intel Compilers and Tools -> Visual Fortran -> Compilers on the Win32 tab, Intel64 or ia32, and why we cannot get the setting back to Intel64 once it has been changed to ia32?

We see 1 as a nice to have, whereas 2 is more important for having the correct settings on our various machines for future applications.

Regards,

Henrik

The appearance of “intel64”

Kevin_D_Intel — Tue, 17 Jan 2017 19:36:41 GMT

The appearance of “intel64” in the path is expected with our PSXE 2017 release. It is tied to our new merged ifort 17.0 executable with capabilities for generating code for both 32-bit and 64-bit targets.

For the typical IDE build, the appropriate additional targeting option is passed in the compilation step; however, for your ia32 custom build step the missing option is /Qm32. Please try adding this to your custom build step. By default, the merged executable targets intel64, which explains the absence of the error 8110 for that configuration.

Hello Kevin,

Sorensen__Henrik — Wed, 18 Jan 2017 10:41:05 GMT

Hello Kevin,

Thank you so much for the reply. It solves our problem with the post build event, and in addition makes good sense.

Our remaining problem is now the setting for Executables under Tools -> Options -> Intel Compilers and Tools -> Visual Fortran -> Compilers on the Win32 tab. While experimenting with the post build event problem we changed the setting from Intel64 to ia32 in Visual Studio 2013. It worked but ia32 is not the value it should have, it should be Intel64. The problem is that every time we change the setting to Intel64 and restarts Visual Studio 2013 it flips back to ia32.

How can we make the setting stay at Intel64? Is there some config file or registry setting we can change?

The good news is that there is no coupling between the setting in Visual Studio 2013 and in Visual Studio 2015, so I assume it is a config file or registry setting in the Visual Studio 2013 context. However, it is related to the Intel plug in which I why I ask you for help.

Regards,

Henrik

Advice from Development work

Kevin_D_Intel — Wed, 18 Jan 2017 10:56:40 GMT

Advice from Development work for me so let me share w/you. On my system where I have 17.0 Update 1 installed and ia32 appears in the path, resetting the Option settings corrected it to intel64. It appears ia32 in the path is a residual setting from earlier installed releases and after the reset it changes to intel64 and it persists across VS restarts.

Try doing a reset on the option settings. Under Options > Intel Compilers and Tools > Visual Fortran > Compilers where you have selected compiler set to <Latest>, click Reset and select “Reset settings for selected compiler only”.

Kevin, I too was surprised by

mecej4 — Wed, 18 Jan 2017 13:26:00 GMT

Kevin, I too was surprised by the changed behavior of working batch files when, even in a Composer IA32 command window, the compiler driver became a 64-bit EXE (in effect, a cross compiler).

Part of the reason for surprise and confusion was that the new versions (2017, 2016U4, ..?) still installed a 32-bit compiler driver as in earlier versions, but this driver was not used when the IA32 or Intel64 Icl/IFort command windows were used. On the other hand, my old scripts used the 32-bit driver, causing problems with the incorrect MSPDBxxx.dll, etc.

Had the 32-bit Ifort.exe/Icl.exe been omitted, instead of being installed but left unused, I would have noticed the change and read through the release notes. If the 32-bit compiler drivers serve a purpose on a 64-bit version of Windows, it is not clear what that is.

Hello Kevin,

Sorensen__Henrik — Wed, 18 Jan 2017 15:26:06 GMT

Hello Kevin,

Using the Reset button as you suggested for sure solved the problem. Thank you.

Regards,

Henrik