I have a large program that’s been converted to using the newunit specifier for most file I/O applications. The program runs fine compiled with ifort 16, ifort 19, and gfortran 12. It crashes while running when compiled with ifort 2021.7, however. It seems to be reusing units, with 2 files pointing to -129 and 2 pointing to unit -131.
Has anyone else encountered this? Is this a known compiler bug, or am I doing something wrong?
It has a multi-threaded version, but the one I'm testing is fully single-threaded. The multi-threaded versions work fine with the other compilers, though.
Another data point: 2021.4 also has collisions with newunit. I saw in this thread that changes were made to newunit around this time. https://community.intel.com/t5/Intel-Fortran-Compiler/Running-out-of-valid-logical-units-from-newunit/m-p/1336989
It seems like this bug has returned. While you await a fix...
I suggest you write your own work around to obtain a unit number. Say, a function that obtains a unit number together with one the relieves the unit number
aUnitNumber = MyNewUnit() ! Obtain an arbitrary unit number (or 0 if none available)
aUnitNumber = MyNewUnit(desiredUnitNumber) ! Obtain an specific unit number (or 0 if not available)
err = MyReturnNewUnit(closedUnitNumber) ! return unit number to pool/table or error if not formerly taken
Note, make the code thread-safe.
I don't have a small reproducer because I've been so confused as to what exactly is happening to try to narrowly reproduce the behavior.
For now, I seem to be able to get around the problem by replacing a section of code, which was essentially
close (unit1) close (unit2) open(newunit =unit1,...) open(newunit = unit2,...)
And instead `inquire`ing if the files are open already (for subsequent passes), and if so, `rewind`ing them instead of closing and reopening and calling newunit again.