Incompatibility between LIBIFCOREMD.DLL versions

[mecej4]

On Windows 11, Fortran sources compiled with Ifort Intel(R) 64, Version 2021.11.1 Build 20231117_000000, may be incompatible with objects compiled with earlier versions of Ifort. Such objects may well exist in third party libraries (IMSL, NAG, etc., or even Parallel Studio). I suspect that the incompatibility is located in the different versions of LIBIFCOREMD.DLL

Here is an example to demonstrate the problem.

The test program

program readfil
   implicit none
   integer fuinc, ios, lno
   character(len=14)  fname
   character(len=130) limage
!
   fname = 'tfile.txt'
   fuinc = 11
   lno = 0
   open(fuinc,FILE=fname,STATUS='OLD',ACTION='READ')
   rewind (fuinc)
   do
      read(fuinc,'(a130)',IOSTAT=ios) limage
      if(ios < 0) exit
      lno = lno+1
      print 10,ios,lno,trim(limage)
   end do
   close(fuinc)
   stop 'Completed'
 10 format(1x,i4,2x,i4,'|',A,'|')
end program

reads the text file "tfile.txt" containing ten lines of text

Alpha
Beta
Gamma
Delta
Epsilon
Zeta
Eta
Theta
Iota
Kappa

The file uses the Unix convention for text files (EOL = LF only):

T:\FAKED\ASIZN2\src\D4only>xxd tfile.txt
00000000: 416c 7068 610a 4265 7461 0a47 616d 6d61  Alpha.Beta.Gamma
00000010: 0a44 656c 7461 0a45 7073 696c 6f6e 0a5a  .Delta.Epsilon.Z
00000020: 6574 610a 4574 610a 5468 6574 610a 496f  eta.Eta.Theta.Io
00000030: 7461 0a4b 6170 7061 0a                   ta.Kappa.

Here are the steps to build and reproduce the error.

1. Build in a OneAPI 64-bit command window: ifort /Od /MD /QxSSE2 /traceback fread.f90
2. Check that the input file tfile.txt is located in the same directory as the EXE that was just built, and run the program. The output is normal, EOF being detected using IOSTAT /= 0.
3. Now open an older IFORT/Parallel Studio 64-bit command window (I used the 19.3 Update 3), change to the same directory as in 1. and 2., and run the EXE again (do not recompile or link!).  We see the same ten lines as in Step 2, but that be followed by:

forrtl: severe (24): end-of-file during read, unit 11, file T:\FAKED\ASIZN2\src\D4only\tfile.txt
Image              PC                Routine            Line        Source
libifcoremd.dll    00007FFD8FA446CA  Unknown               Unknown  Unknown
libifcoremd.dll    00007FFD8FA9BF76  Unknown               Unknown  Unknown
fread.exe          00007FF6FBBC11CC  MAIN__                     13  fread.f90
fread.exe          00007FF6FBBC141B  Unknown               Unknown  Unknown
fread.exe          00007FF6FBBC175C  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFDBFE8257D  Unknown               Unknown  Unknown
ntdll.dll          00007FFDC136AA58  Unknown               Unknown  Unknown

When the last line has been read, the next READ should return IOSTAT=-1. In the OneAPI command window, it does, and the DLL is C:\LANG\OneAPI\compiler\latest\bin\libifcoremd.dll . In the Ifort 19.1U3 command window, the DLL used is C:\LANG\PS20\compilers_and_libraries_2020.4.311\windows\redist\intel64\compiler\libifcoremd.dll .

[mKlapwijk]

Nice write up and reproducer. I ran into exactly the same problem last week on windows 10 with oneAPI 2024.0.0 and 2023.1.0

I also suspect the problem to be in the libifcoremd.dll. The annoying part is that the location where the libifcoremd.dll is located has changed from the 'redist' folder to a higher level folder, which led in my case to the problem to occur.

The fact that this changed was not directly obvious.

[Barbara_P_Intel]

The new directory layout introduced with oneAPI 2024.0.0 is documented in the release notes.

For detailed information about the Unified layout, including how to initialize the environment and advantages with the Unified layout, refer to Use the setvars and oneapi-vars Scripts with Linux and Use the setvars and oneapi-vars Scripts with Windows.

[Ron_Green]

What you are doing is creating .exe with 2024.0 but running that .exe with the older Fortran runtime DLLs from 19.1 U3.  That is not recommended.  Going 'backward' to older FRTL DLLs across major release versions is never recommended.  I am not even sure if 19.1 U3 supports Win11.  I'd have to check the Release Notes and System Requirements for 19.1 U3, because that FRTL DLL was built a while ago.  Not sure when Win11 came out.  Let me research this strange combo of new .exe with old FRTL DLL.  It's certainly not a supported use case.

[Ron_Green]

@mecej4 
I am not sure what ifort package you are using for the 'old' FRTL.  From HERE I see that 19.1 U3 was linux only.  There was a U2 and and U4 for 19.1 for Windows.  the 'newest' 19.1, U4 was built 20200925.   At that time, Win 11 did not exist.  Win 11 released in 20211005

So running that compiler on Win 11 is unsupported, including using it's FRTL on a Win 11 system.

On top of all this, we have made fixes to the FRTL for handling IOSTAT specifically.  These went into the oneAPI 2024.0 compiler, ifort v 2021.11.x 

Using an older .exe with a NEWER FRTL dll(s) we support and should work.  Using a .exe compiled with a newer compiler with an older FRTL DLL(s) is not supported nor recommended. 

[Ron_Green]

@mKlapwijk I may need more details about your situation.  As I said, there was a fix for IOSTAT issues in 2024.0.  The bug would exist in 2023.1.  Can you confirm that the application runs as expected when compiled with 2024.0 and run with the 2024.0 environment, picking up the 2024.0 FRTL dlls?

[mKlapwijk]

@Ron_GreenIndeed the application runs as expected when compiled with 2024.0 and using the 2024 dlls.

I agree that using the older dlls should not be supported nor recommended. In my case it was not immediately clear that that was what happened.

Background:
We compile the binary and copy the dlls into one directory which we can easily pass to users who do not have the full intel oneAPI package installed. Since the location of the dlls changed, the copying step could not find them (and I did not spot the warning). Since I had not cleaned the target directory, the 2024 binary was put next to the 2023 dlls, which resulted in a not correctly working application.

When you ran the application it did start but crashed on this iostat bug.

The problem is definitely on our side, we need to fix the script to not use a hard-coded path (or at least it needs to be corrected).

[JohnNichols]

I think you have strayed a bit from @mecej4 's original point that Such objects may well exist in third party libraries (IMSL, NAG, etc., or even Parallel Studio).

This is becoming a common issue in other languages that develop fast and old packages from long forgotten developers are still useful. 

DISLIN was a beast recently to get going, it takes a few days and some help to sort out the subtle changes.  

Side issue:

Jim:

What size reals do you think they used in coding EXCEL?  I can exactly replicate their full linear regression model, but matching the probability is not possible without using the large reals you showed in an earlier post.  The interesting feature is EXCEL's Standard Error does not match the textbook's equation, EXCEL uses a t STAT of one to determine the standard error in the linear regression.  It is interesting, but different. 

Apologies, I am too lazy to find the other post and Jim reads everything. 

John

[andrew_4619]

excel - ask wiki https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft_Excel#:~:text=With%20some%20exceptions%20regarding%20erroneous,a%20few%20other%20data%20types).

[JohnNichols]

That is as I thought it would be. 

EXCEL in linear regression, gives t Stat values of say 6000, with dof of several hundred thousand, you cannot with double precision calculate the p value for the (t Stat, dof) pair,  but EXCEL gives a value, using the limits on double precision, I am a multiple off of the EXCEL values, the multiple is like 10 ^ 50.

Jim shows how to do it with quads- I think they are called.  

Anyway, I will run with mine.