I have a simple file (C091G12.rrd) with two numerical fields for each line that can't correctly be read with a fortran code compiled with ifort.
It seems that the program (I extracted and simplified the relevant part in the attachment) fails to recognize the end of the file.
The issue is present with the following versions of the compiler:
1) On MacOS: ifort (IFORT) 17.0.1 20161013
2) Linux: ifort (IFORT) 18.0.0 20170811
On the other hand, the issue is not present with ifort (IFORT) 16.0.3 20160415 (Linux) or with gfortran.
An additional piece of the puzzle is that the file is read correctly if I slightly modify the file, e.g., by removing any of the lines or adding a trailing zero to any of the numbers.
I would also note that the file is automatically generated by a Python script within a pipeline that generates tens of these files every day and this is the first time that the fortran code fails to read it.
I looked into your test case on MACOSX with gfortran 9.0.1, and on Linux with PGI 19.1, nagfor 6.2, gfortran 5.4, and ifort 18.0.5 and ifort 19.0.2. No isses. WIth ifort 17.0.8 I see a segmentation violation with the following backtrace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000000000441441 in for.get_s ()
#0 0x0000000000441441 in for.get_s ()
#1 0x000000000040f73d in for_read_seq_lis ()
#2 0x0000000000402b90 in MAIN__ ()
Is that the issue that you see? It could be some bug that seem to have been fixed in the 18.0.5 (at least) and 19.0.X branches.
I get the following error message from the test program:
ERROR IN READING FILE 59
59 is the IOSTAT output from the READ command.
Essentially, the end-of-file is not recognized and the next time the program tries to read the two numerical values it fails.
Thanks for letting me know that things work with a more recent version of the compiler.
I guess that the question is whether this was a known bug and got fixed or some other change makes the compiler work on this specific case without actually fixing the bug.
In the latter case the bug could manifest when reading a different file.