since the last update of ifort, I get the runtime error: "A non-advancing READ immediately following a non-advancing WRITE on the same unit number is not allowed, unit 5".
I show below a simplified version of the part where the error is produced (this sample works well with gfortran and nagfor). I need to use advance='no' in the read statement since the length of the record is not known.
The error message is somewhat ambiguous and surprising since the units are not the same.
In this example, the error is reported at the 2nd iteration.
use, intrinsic :: iso_fortran_env, only: uin=>input_unit, uout=>output_unit, uerr=>error_unit, iostat_eor implicit none integer, parameter :: lstr = 1000, mstr = 100 integer :: iostat, size, i character(len=lstr) :: iomsg character(len=mstr) :: buf character(len=: ), allocatable :: line do i = 1, 10 ! print the prompt: write(uout, '(a)', advance='no') "--> " ! read until end-of-record: line = '' do read(uin, '(a)', advance='no', iostat=iostat, iomsg=iomsg, size=size) buf if (iostat > 0 .or. (iostat < 0 .and. iostat /= iostat_eor)) then write(uerr, '(a)') trim(iomsg) stop end if line = line // buf(:size) if (iostat == iostat_eor) exit end do write(uout,'(a)')'line = '//trim(line) end do end
Hi Ferdinand and thank you for your comment and example.
Yes, I indeed forgot to put the flush statement in the sample but is well present in my real code. Unfortunately (and even with your example) it crashes with the aforementioned message when compiling with ifort 19.1 (for mac) but it doesn't when compiling with the previous version (19.05).
Maybe this issue is caused by changes in how the fortran runtime interacts with buffered terminal in/output?
Consider this (which crashes on the same error):
read(5, *) write(6, '(a)', advance='no') 'x' !; flush(6) read(5, '(a)', advance='no') end
But if you comment in the flush statement, it works.
So as a workaround, you could try to flush(uout) in line 14.
EDIT (in response to #3) ---------------------------------------------
Results for the above (short) example, generated on Red Hat Enterprise Linux Server release 7:
VERSION NO FLUSH WITH FLUSH 18.104.22.168 crash ok 22.214.171.1244 crash ok 126.96.36.1996 crash crash 188.8.131.528 ok ok
I had tested on linux, see my updated post (#2).
Alternatively, would if work if you simply ignored the error? On my setup I got iostat=126, so how about adding line 19 as follows:
if (iostat == 126) cycle
Of course, this does neither fix nor explain the origin of the error...
I will adopt your solution (but IOSTAT values are certainly not standard, most likely compiler dependent) and, in the meantime, I will report the problem to the Online Service Center.