Solved: READ command with IOSTAT does not capture end of file and returns error instead - Page 2

Feng__Jesse · ‎09-28-2023

I have two workstations running two versions of Intel Fortran, one with:

And the second one:

The following read code works in the second version but does not work in the first version:

SUBROUTINE READSEC()

IMPLICIT NONE
CHARACTER(LEN=100) :: CURRENTLINE
INTEGER,PARAMETER :: FID=15,NVAR=10
INTEGER :: I,J,IOS,NHEADER,NPHSEC
LOGICAL :: READHEADER

READHEADER=.TRUE.

OPEN(UNIT=FID,FILE = TRIM(WORK_DIR) // FNSEC, IOSTAT=IOS,ACTION='READ')
!DETERMINE LENGTH OF HEADER AND NUMBER OF SECTIONS IN FILE
NHEADER=0
NSEC=0

DO
   
   IF(READHEADER)THEN
      READ(FID,'(A)', IOSTAT=IOS) CURRENTLINE
   ELSE
      READ(FID,*, IOSTAT=IOS)
   ENDIF
   
   IF ( IOS .GT. 0 )THEN
      !ERROR STOP "ERROR OPENING FILE *.SEC"
      CALL STDB_ABQERR(-3,"ERROR OPENING FILE: "// TRIM(WORK_DIR) // FNSEC ,(/INTEGER::/),(/REAL::/),(/CHARACTER(8)::/))
   ELSEIF(IOS .LT. 0 )THEN
      EXIT !END OF FILE
   ELSE
      IF(READHEADER)THEN
         NHEADER=NHEADER+1
      ELSE
         NSEC=NSEC+1
      ENDIF
	    
      IF(CURRENTLINE.EQ.'*DEFINE SECTIONS')READHEADER=.FALSE.
   ENDIF
ENDDO

ENDSUBROUTINE

This is the first part of this read subroutine. The purpose is to determine the total number of data lines in the file for reading later.

Specifically, in first workstation with 2021.10.0, the code successfully reads all the lines in the attached file, New01.SEC (I changed the extension from sec to txt to upload), then when it returns back to line 21, instead of canceling the read operation and set IOS to -1 for end of file, it just attempts to read the line normally and fails with an end-of-file error instead. Again, this does not happen in the second workstation with 2021.4.0.

I tried many ways to debug this but I cannot figure out why. The compilation flags used for this code are also attached. Can anyone else replicate this? Any suggestion on how to figure out the source of this issue would be much appreciated!

mnolaya · ‎10-02-2023

UPDATE

I managed to resolve the issue, but I'm not sure I can explain the reasoning for it on any deep level. Took me a while to get there as I had to dig up the old installer for OneAPI back to 2021.4: Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.4.0 Build 20210910_000000.

Because I reverted back to 2021.4, I could no longer integrate with VS2022, meaning I also had to revert back to VS2017 or 2019. Unfortunately, this came with its own issues -- the 2021.4 installer would crash due to some issue with a DLL file that came with VS2022 as discussed on Intel's known issues pages here and on the forums here.

Ultimately, the solutions provided in the above links didn't work for me. What did however was first uninstalling VS2022, then repairing my 2019 installation. Then, I went ahead and tried to install 2021.4 with no crashes and integration with VS2019 confirmed.

I don't know if the problem was the compiler version or with VS2022, as I could not integrate the two to test and confirm. However, if you have the ability to do this, I would consider it a possible solution to explore @Feng__Jesse. Good luck. I'll check back in on this thread in case you have questions.

@andrew_4619to answer your question about build command & runtime libraries -- I'm pretty much a novice at a lot of what VS offers as well as the terminology. I attached an example of the output from building one of the static libs, which uses the same commands and options as all of my static libs in the overall solution. Let me know if there's anything that seems out of place.

View solution in original post

Istvan77 · ‎10-15-2025

I provided in my post the full reproducible example source code and the simplest command link to build: ifx -MD test_read.F

There is no mixing of runtime libraries. I asked for the dynamic runtime. I provided the specific compiler versions.

andrew_4619 · ‎10-16-2025

C:\tmp>ifx -MD test_read.F
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.2.0 Build 20250605
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.

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

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

C:\tmp>test_read
 IS_IOSTAT_END          -1
end: read 26 lines

C:\tmp>

Look at the code this seems like correct behaviour. Is this the expected result?

Istvan77 · ‎10-16-2025

Thanks for testing, yes, that is the correct result - and it is not what I get when building with -MD. I use Visual Studio 2022 Version 17.12.4 on Windows 11.

andrew_4619 · ‎10-16-2025

I made it with -MD. (ifx -MD test_read.F) as per session posted.

Are any other options required?

Are you running the exe in vs , if so Are the results the same if you run externally?

The most likely option is that some old/incompatible run time dlls are being found in the Path.

I would suggest having a search for the two dlls highlighted to see where they are and what the pedigree is

Istvan77 · ‎10-16-2025

Thanks for the clues

indeed if I do

set PATH=c:\Windows\System32;c:\Windows;c:\Program Files (x86)\Intel\oneAPI\compiler\2025.2\bin

test_read.exe

IS_IOSTAT_END -1
end: read 26 lines

-- this is the correct behavior --

I'll need to narrow down which dll is the culprit. If i run from visual studio debugger (with full paths i reproduce the bad behavior)

the two suspects are below

'test_read.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Program Files (x86)\Intel\oneAPI\intelpython\python3.9\Library\bin\libifcoremd.dll'. Module was built without symbols.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Program Files (x86)\Intel\oneAPI\vtune\2025.4\bin64\libmmd.dll'. Symbol loading disabled by Include/Exclude setting.
The thread 9008 has exited with code 0 (0x0).
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. Symbol loading disabled by Include/Exclude setting.
'test_read.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Symbol loading disabled by Include/Exclude setting.

.. and the bad dll is: C:\Program Files (x86)\Intel\oneAPI\intelpython\python3.9\Library\bin\libifcoremd.dll

which indeed is an ancient version

this path is set up by call "C:\Program Files (x86)\Intel\oneAPI\setvars.bat" intel64 vs2022

could be done something either from the oneapi installers or the setvars.bat scripts to not include the path

C:\Program Files (x86)\Intel\oneAPI\intelpython\python3.9\Library\bin ? Or to make sure it contains a new version of the dll?

Thanks

Istvan

andrew_4619 · ‎10-16-2025

Do you use that python version? I always install the full oneapi base kit + hpc kit. I do not have that folder. It is either a separate instal or left over junk from something older. I would look to uninstall that and remove that path entry. Maybe uninstall everything and do a clean install.

Istvan77 · ‎10-16-2025

Hello, indeed doing a clean install sounds appealing, however, i keep the old compiler versions to test -- it is very useful that especially today -- so far different versions happily coexists in different folders, and by the intel setvars.bat configfile mechanism I am able to select the desired version. My oldest compiler version in that suite is 2021.2.0.

Somehow this Intel Python folder is causing the trouble. Now that i know about i'll delete it, but the installer/setvars could also detect and save the user from trouble.

Thanks for your support,

Istvan

andrew_4619 · ‎10-17-2025

For these reasons I always download the full offline installers and file them away after use on an external backup drive! You are asking a lot when you consider the number and complexity of the products and the huge number of permutations of old stuff a user can have installed. Testing all that is not a realistic expectation given everyone had finite resources. A fresh start from time to time avoids a lot of these problems.

Steve_Lionel · ‎10-16-2025

Having multiple copies of the compiler DLLs on the system leads exactly to the problem you saw. The "intelpython" install should not have put its own copy of libifcoremd.dll in its folder that shows up first in PATH. Delete it. The libmmd.dll under Vtune really should not be there either.

Steve_Lionel · ‎10-17-2025

You don't need a clean install, and that may not help anyway if some other product is making the DLL appear first in PATH. The easiest and best solution is to edit the system PATH environment variable to make sure that c:\Program Files (x86)\Intel\oneAPI\compiler\latest\bin is in PATH before other non-system DLL locations.

andrew_4619 · ‎10-17-2025

Yes it can be fixed that way but a clean install in this instance would remove some of the dross the inevitably accumulate if you use a machine for any length of time but the OP can do whatever, that is what I would do.