Latest Ifort 32-bit console program crashes on STOP statement

[mecej4]

The current version of Ifort, when used to build the following program with the /MD option, produces a 32-bit EXE which, when run, puts up an error notification when it reaches the STOP statement.

The problem does not occur with 64-bit EXEs or if /MT is used for 32-bit compilations. The problem also occurs in other 32-bit console mode programs that were compiled with /MD when a STOP statement is executed.

The pop up error notification says "The procedure entry point for_stop_core_quiet could not be located in the dynamic library T:\LANG\hw.exe." and has an "OK" button.

T:\LANG>copy con hw.f90
program hw
print *,'Hello World'
stop
end
^Z
        1 file(s) copied.
T:\LANG>ifort /MD hw.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on IA-32, Version 2021.5.0 Build 20211109_000000
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.28.29334.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:hw.exe
-subsystem:console
-incremental:no
hw.obj

T:\LANG>hw

[Steve_Lionel · Accepted solution]

The problem is that you have an older Intel compiler runtime DLL on your system. I tried your test case and it worked for me.

D:\Projects>type t.f90
program hw
print *, "Hello World"
stop
end
D:\Projects>ifort t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on IA-32, Version 2021.5.0 Build 20211109_000000
Copyright (C) 1985-2021 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.29.30139.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
 Hello World

D:\Projects>

Try this. Download and install https://registrationcenter-download.intel.com/akdlm/irc_nas/18412/w_ifort_runtime_p_2022.0.0.3663.exe - this is the latest Intel Fortran Compiler runtime. For reasons unfathomable to me, Intel stopped including the current runtime library with the compiler install, and doesn't even suggest installing it separately. You can find the latest at https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html (you have to use the menu at left to drill down - a direct link is not available.)

Make sure that there are none of the Intel run-time DLLs in your project folder.

[mecej4]

Thanks, Steve. I had already downloaded and installed the runtime for OneAPI 2022 a few weeks ago. Nevertheless, I download and ran the installer again. It detected that the runtime package was already installed ("Change" grayed out) but offered to repair or remove. I selected "repair".

The "for_stop_core_quiet not found" problem remains (this is only for 32-bit EXEs built with the 2021.5 Ifort compiler; 64-bit EXEs run fine; even 32-bit EXEs run fine until the program tries to stop with a STOP statement.)

I build at the command line (using the OneAPI 32-bit shortcut from the Start menu). I never copy the compiler DLLs to any working directories, relying instead on having %PATH% set so that the DLLs can be found wherever they were installed with the Intel compilers.

Here are some bits of diagnostic information.

T:\LANG>where libifcoremd.dll | findstr /v 64
C:\LANG\OneAPI\compiler\latest\windows\redist\ia32_win\compiler\libifcoremd.dll
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\ia32\libifcoremd.dll
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler\libifcoremd.dll

Note that the OneAPI version occurs first in the list. I ran "dumpbin /exports ...libifcoremd.dll | findstr /v 6" on each of the three versions, and each of the three DLLs does contain the "for_stop_core_quiet" entry point. I opened the OneAPI version of the DLL in Dependency Walker, and it showed for_stop_core_quiet.

I found that the 19.1.3 compiler generates a call to "for_stop_core" whereas the 2021.5 compiler calls "for_stop_core_quiet". I ran the EXE generated by the 19.1.3 compiler inside the OneAPI command window, and it ran fine. I tried the reverse (EXE generated by Ifort 2021.5 run in 2019.1.3 command window), and it failed.

[Steve_Lionel]

for_stop_core_quiet supports the new F2018 QUIET= specifier for STOP.  The example I tried calls _for_stop_core_quiet (the 32-bit entry point) and it was found. I even tested with a bare command prompt (not the one that defines ifort) and the program runs.

More interesting is the value of PATH, and which 32-bit libifcoremd.dll is found first in PATH. I'm going to guess that some other software added to path a folder with an older version of the DLL.

[mecej4]

I found old (2009) versions of libifcoremd.dll, libifportmd.dll and libmmd.dll in the Windows\Syswow64 directory, and I can't think of which software on my 1 year old NUC caused those DLLs to be installed.

%PATH% contains %windir%\system32, which I suppose gets redirected to %windir%\syswow64. Is it possible that DLLs in Syswow64, even though not in %PATH%, get picked up because of this redirection?

Anyway, I moved those three DLLs to a holding directory, and that solved the problem.

You are correct, the 2009 libifcoremd.dll does not have the for_stop_core_quiet entry point.

Why should a simple STOP statement cause the compiler to generate a call to for_stop_core_quiet, when the programmer did not append the clause ",QUIET=.TRUE." to the STOP statement?

Thanks.

[Steve_Lionel]

I have seen some third-party programs install the Intel DLLs into the System folders, which is lazy and wrong.

for_stop_core_quiet has a different calling sequence that supports the possibility of QUIET. I suppose the compiler could decide to call the old routine if QUIET is not specified, but that's more complex and breaks the rule to use libraries at least as new as the compiler.