Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
47 Views

issue found in intel libraries between windows 7 and windows 10

We are building an MDI windows application under windows 7 with MS visual studio 2015 and intel fortran 17.1.   The GUI set up has been working to our knowledge on windows 7 but fails (crashes) if we run the same application on a windows 10 computer.  Similarly rebuilding from the same source code on windows 10 (same compilers) still crashes on windows 10.    The IT support people have traced this to what is believed to be a bug in the ifort libraries.   They were able to reproduce the crash with an MDI example code as documented below:

 

Scott,

Good news. It turns out that it is easy to create a test case that demonstrates the problem.

 

Launch Microsoft Visual Studio

Select File > New > Project

In the New Project window, select a project type under Intel(R) Visual Fortran

Select this project type :      Multiple Document Interface (MDI) sample code

 

Build a 64 bit solution in release mode.  

 

Launch the binary. Select File > New

 

An MDI child window MDI 0 will appear on a Windows 7 machine, but will crash on Windows 10.

 

It’s that easy.

 

Would it be possible for you to enter the report, since you already have an account?

 

Intel may have  already fixed the problem. I see that they are on version 19.0 while I am running version 10.1.021

 

Dennis created the sample MDI test-case with Visual Studio.  I built the 64 bit version with command line tools  and tested it on windows 7 (worked) and windows 10 (crashed).  

 

The above is probably enough for the ticket. If you want to give them more, here’s the technical jargon:

 

These three lines appear in the template sample code (WinApp1.f90 line 552) generated by the Fortran Application Wizard.

 

            ! INFO was allocated in the MDIWndProc at IDM_NEW time and is

            ! passed to us at WM_CREATE time...

            hInfo2 = SetHandle (lParam)

 

The assembly code of SetHandle (resides in ifwin.lib)  thinks the address of lParam is 32bits. It uses this instruction  movsxd rcx,ecx to sign extend to 64 bits.

On Windows 10, the high order bit of ecx is on causing the address in rcx to be huge. On Windows 7 the high order bit of ecx is always off so it works there.

 

rcx=000000439a0e4940

rcx=ffffffff9a0e4940

-----------------------------------------------------------------------------------------------------------------------------------------------

Again, we are using ifort 17.1.   We would like to hear if this is a known bug; if it has been fixed since 17.1 was released.   We think that perhaps we will be going to evaluate ifort 20 when it comes out to see if we can validate this compiler version with our application.  If it works, that would be the next relase for our team to migrate to.   If it hasn't been fixed, we would hope the version 20 could include a fix for this.

 

thanks

scott

 

 

0 Kudos
4 Replies
Highlighted
Black Belt
47 Views

The problem persists in Ifort 19.0.3-64 bit on Windows 10-64. Your IT staff have pinpointed the error down to the exact instruction that is in error (movsx instead of movzx). Please report the bug at the appropriate place using the required procedure, see https://software.intel.com/en-us/support/priority-support .

0 Kudos
Highlighted
New Contributor I
47 Views

Thank you. Your request has been submitted.

Your Support request number is 04191787

Summary

Request04191787

Created ByScott

Status NewClosed

Created Today 09:58 PM

Products or Services Intel® Fortran Compiler for Windows*

Last Updated Today 09:58 PM

Customer Description bug in intel fortran libraries when run on windows 10

0 Kudos
Highlighted
New Contributor I
47 Views

thanks

 

 

0 Kudos
Highlighted
Valued Contributor III
47 Views

I looked at this. The code uses modules USER32 and KERNEL32 but neither of these has an interface defined for SETHANDLE and indeed this API routine does not seem to be documented at MSDN. Clearly the linker does resolve this call in one of the standard windows libs but I would suggest that the IFORT sample code should not be using this routine...

0 Kudos