I have used this format statement for quite a while and I don't see anything wrong with the program or data - [dir:~/tests/gfortran] dir% gfortran -o fread01 fread01.f [dir:~/tests/gfortran] dir% fread01 < fread01.dat At line 6 of file fread01.f Fortran runtime error: Bad value during integer read [dir:~/tests/gfortran] dir% cat fread01.f program main dimension x(10),y(10),z(10) integer idt(6) character*1 it,jpr 10 read(5,1000) it,n,jpr,(idt(i),i=1,6),x(n),y(n),z(n),kn, 1 nrst,mids write (6,2002) it,n,idt,x(n),y(n),z(n),kn,nrst,mids stop 1000 format (a1,i4,a1,i4,5i5,3f10.0,3i5) 2002 format(2x,a1,2x,i5,5x,6i5,3f13.4,5x,i5,i7,i6) end [dir:~/tests/gfortran] dir% cat fread01.dat 1c 1 1 0 1 1 1 0. 1.225E-15 20.000000 1 2c 1 1 0 1 1 1 0. 1.194E-15 19.500000 1
gfortran seems to handle incorrectly the case when we ask for more integers than we provide (Intel compiler, for example, set j and k to 0 in the following case). Reduced testcase: $ cat a.f program main implicit none integer i,j,k character c read(5,'(a1,3i5)') c,i,j,k end $ cat data c 1 c 1 The error message is: At line 5 of file a.f Fortran runtime error: Bad value during integer read If the second line of the data file is removed, the message becomes: "Fortran runtime error: End of file" Reproduced on i686-linux and sparc-sun-solaris2.9
Confirmed with the reduced testcase, G77 does the correct thing also.
I'm not sure, but I guess this one should go away with Thomas' patches for EOR handling (see PR 20131, comment 5 for a link).
Fixed in 4.1, waiting for 4.0.1 to reopen.
Patch committed to 4.0.1. Fixed.