Intel compiled app fails in Windows 10

[Bob_S_3]

I have an application that has been compiled using various versions of windows for about 20 years. We have used intel compilers and IntelMPI for several years.  The app runs effectively under windows 7, but fails under Windows 10 (Program exception access violation). I am using a trial version of intel parallel studio XE 2016 for windows 10 and my licensed Composer XE 2013 on my windows 7 machine.  I have isolated part of the problem to a version of the mesa3D opengl library. I created a simple c main routine that calls the library to render a simple graphic. In order to get the simple app to run I need to add the compiler/link flag /Qauto-ilp32. this suggest to me that the mesa3d library probably has 64 bit issues. However, my real app is written in fortran and I cannot figure out if there is a way to use the /Qauto-ilp32 or equivalent flag when the app is linked using the ifort compiler. Note I have tried all of the windows 10 compatibility settings I could find and none of them worked.

Note we are compiling 64 bit with the windows 7 compilers and using a similar configuration for Windows 10.

I have been able to build 32 bit under windows 7. The serial executables run in Windows 10, but the parallel one do not.

I have not been successful building ia32_intel64 using parallel studio on windows 10.

Is there a way to do the equivalent of auto-ilp32 using the ifort compiler?

Thanks.

[Steven_L_Intel1]

No, there's no ifort version of ilp32. Are you perhaps linking to a 32-bit build of mesa3d?

Rather than Windows 7 vs. Windows 10, it more reads like uninitialized memory access.

You say that the 32-bit version doesn't run parallel. What goes wrong?

[Bob_S_3]

Hi Steve,

Thank you for your response.

I am using the intel64 setup for the compilers used to build the mesa library. I do not use any compiler flags to ask for 32 bit libraries.

I would assume that the auto-ilp32 is a 64-bit only option as it would appear to change a 64 bit pointers/ints to 32 bit. Correct?

I agree that it would appear to be an uninitialized memory read/pointer issue because the 64 bit pointers are apparently being truncated to 32 bits and accessing the wrong memory (my assumption). The auto-ilp32 appears to provide a work around for some bad code or compiler issue somewhere?

The app compiled 32 or 64 bit runs on Windows 7 in both serial and parallel modes. The same 64 bit executables fail in Windows 10 with an access violation. The same 32 bit exes run in serial but fail in parallel. I have tried several things to make them work, but with no success. On windows 10, the command environment is set up to run intelSWtools inclusing intleMPI. The path to the mpi utilities is set to the parallel studio 2016. The smpd and mpiexec commands operate and I am able to run simple mpi test programs. When I try to run the 32 bit parallel executable I get an access violation in impi.dll. I have tried all of the available ways to run: 1) using the windows 7 redistributable mpi utilities for ia32 and em64t 2) using the parallel studio 2016 intel64 tools ( I understand that the ia32 mpi is gone). The 64 bit mpi setups work (I can start/stop smpd and run mpiexec just not my app. The ia32 mpi tools do not appear to operate.  When I try smpd start or stop or mpiexec  the command line just returns without printing any information. I cannot get a status or any other option to return information with this setup. I have tried other things, but at this point I do not really see a path forward with the 32 bit exes. Do you have any recommendations for getting the ia32 mpi tools to operate under windows 10? I definitely could have missed something, but I have not had a problem like this with them before.

It would appear that since the IntelMPI approach is not supporting 32 bit any longer(parallel studio 2016 correct?) that my option is to try and get the 64 bit version to operate correctly. I have traced a problem to the mesa intel64 build and discovered that if I am building a simple c program I can use the auto-ilp32 option to get the build to operate properly. Is there a way to identify what the auto-ilp32 option is doing to the compiled code/libraries? Is there a way to get the auto-ilp32 option to "fix" the library file and save the library (I am using static libraries currently)? I have started to try and rewrite the main program from Fortran to C so that I could try and use the auto-ilp32 option to fix the code.

Thanks.

Bob

[Steven_L_Intel1]

/Qauto-ilp32 is a C-only option and requires that the C compiler be able to "see" the entire program. Its use on libraries is not encouraged. Intel Fortran doesn't have something similar because in Fortran there is not an assumed correlation between integer size and address size.

I recommend that you don't look for quick fixes such as this and identify the real problem, which it would appear is in the mesa3d library and unrelated to Intel Fortran.

The older 32-bit version of Intel MPI can be installed and used - I haven't yet encountered an Intel development tool that works on Windows 7 and fails on Windows 10. I'll mention that Intel Visual Fortran installs the older Intel MPI run-time support for 32-bit coarray applications.