This program writes huge(1d0) to an internal file then reads it back. Both are list-directed. But reading gave Infinity, which looks like an ifort bug. I suspect the trouble is that ifort Version 220.127.116.114 Build 20200925_000000 writes 1.797693134862316E+308, which is > huge(1d0). With the same program gfortran gave 1.7976931348623157E+308, which is correct. Evidence:
johns-laptop:~$ cat testhuge.f90
big = huge(big)
if(ios/=0) print "(A,I0)",'iostat from internal read = ',ios
end program testhuge
john@johns-laptop:~$ intel/bin/ifort -V testhuge.f90
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.104.22.1684 Build 20200925_000000
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.
Intel(R) Fortran 19.1-1655
GNU ld (GNU Binutils for Ubuntu) 2.30
Internal read iostat=64
john@johns-laptop:~$ gfortran testhuge.f90
You created this problem when you used list-directed output to write LINE. This uses a "processor-dependent" format which ends up rounding the last few digits of the value from 3157 to 316. When the rounded value is read in, it is too big for a REAL(8).
If instead you did this:
you would get in LINE the value ending in 3157 and this will read correctly into X.
The moral of the story is to not use list-directed I/O when you care about the formatting.
Here is a similar example to reinforce what Steve L. wrote:
character(len=30) str real x,z x = acos(-1.0) write(str,*)x read(str,*)z print *,tan(x*0.5),tan(z*0.5) end program
The output when IFort is used: -2.2877332E+07 -6137956.
The output from gFortran : -22877332.0 -22877332.0
You cannot use routine evaluations and list-directed I/O with such corner cases.