This program should return 2 zeros if the file psfres.dat consist of 2 empty lines. This is true in case of g77, but gcc version 4.0.0 20041013 reports an end of file error. integer n,m open(unit=8,file='psfres.dat',status='unknown') read(8,'(/2i2)')n,m write(*,*)n,m end psfres.dat ( is just 2 empty lines ) If non empty then it works OK, but this is not fortran standard. I havent check the f95 standard :-( The program is taken from a much larger program (CHARMM), this is why there is / in the format. Another strange behavior is if I put numbers in the firat line (which should be ignored), then there is no eof error in gfortran. g77 behaves OK also in this case.
i concur, it is a libgfortran bug.
after thinking about this some more, i think it is a bug in g77. we are trying to read 3 things, the '/' which consumes the first /n, then two numbers (each I2). the file has 2 /n's in it. from the f77 stnadard: 12.9.5.2.1 Using a Format Specification. If a format specification has been established, format control (13.3) is initiated and editing is performed as described in 13.3 through 13.5. On input, the input list and format specification must not require more characters from a record than the record contains. language lawyers, please comment ! i have suspended work on this until we get some more input; is this a bug or not ? --bud
> > we are trying to read 3 things, the '/' which consumes the first /n, then two > numbers (each I2). the file has 2 /n's in it. > I simplified thing and threw out the / from format specification. If I put 2 empty lines in the psfres.dat file I get the two zeros. This is improvement!! I am using 4.0.0-20041212 snapshot. But still I need only one empty line for g77. However if I put only 2 space characters in the one line psfres.dat then I get 2 zeros. So we are almoste there.... I think this is what always worked in fortran even in the days of punch cards: the blank card always produced zeros when read in the input deck.
I'm no language lawyer, but this works (returns two zeros and no error) for Sun, PGF, IBM, MIPSpro and Intel compilers. I think this should be considered as a bug (I confirm it is still present in CVS).
Subject: Bug 17992 CVSROOT: /cvs/gcc Module name: gcc Changes by: tkoenig@gcc.gnu.org 2005-04-10 08:35:40 Modified files: libgfortran : ChangeLog libgfortran/io : transfer.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: eor_handling_1.f90 eor_handling_2.f90 eor_handling_3.f90 eor_handling_4.f90 eor_handling_5.f90 noadv_size.f90 pad_no.f90 Log message: 2005-04-10 Thomas Koenig <Thomas.Koenig@online.de> PR libfortran/17992 PR libfortran/19568 PR libfortran/19595 PR libfortran/20005 PR libfortran/20092 PR libfortran/20131 PR libfortran/20138 PR libfortran/20661 PR libfortran/20744 * io/transfer.c (top level): eor_condition: New static variable. (read_sf): Remove unnecessary zeroing of buffer (there is enough information in its length). Return a string of length 0 (to be padded by caller) if EOR was seen previously. Remove erroneous special casing of EOR for standard input. Set eor_condition for non-advancing I/O if an end of line was detected. Increment ioparm.size if necessary. (formatted_transfer): Skip the function if there is an EOR condition. (data_transfer_init): Initialize eor_condition to zero (false). (next_record_r): Clear sf_seen_eor if a \n has been seen already. (finalize_transfer): If there is an EOR condition, raise the error. 2005-04-10 Thomas Koenig <Thomas.Koenig@online.de> * eor_handling_1.f90: New test case. * eor_handling_2.f90: New test case. * eor_handling_3.f90: New test case. * eor_handling_4.f90: New test case. * eor_handling_5.f90: New test case. * noadv_size.f90: New test case. * pad_no.f90: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.188&r2=1.189 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.35&r2=1.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5320&r2=1.5321 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/noadv_size.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pad_no.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed in 4.1.0, waiting for inclusion into 4.0.
(In reply to comment #6) > Fixed in 4.1.0, waiting for inclusion into 4.0. I just tried 4.1-20050410 and the problem is still there. So what was fixed? Or maybe the patches are not in this snapshot yet?
(In reply to comment #7) > (In reply to comment #6) > > Fixed in 4.1.0, waiting for inclusion into 4.0. > > I just tried 4.1-20050410 and the problem is still there. So what was fixed? Or > maybe the patches are not in this snapshot yet? Are you sure that you are using that version? I would not trust gentoo.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Fixed in 4.1.0, waiting for inclusion into 4.0. > > > > I just tried 4.1-20050410 and the problem is still there. So what was fixed? Or > > maybe the patches are not in this snapshot yet? > Are you sure that you are using that version? > I would not trust gentoo. Gentoo has gcc-config command with which one can choose among installed gcc versions. After that I always run also gfortran --verbose which tells me the version which I use. This is GCC's command, so I think I can trust it ?? Also I noticed about 6% speedup in execution time over gcc-4.0, so I guess I am using the new stuff.
Can you try with a later build and tell us what your exact source and output is? $ cat psfres.dat $ cat pr17992.f integer n,m open(unit=8,file='psfres.dat',status='unknown') read(8,'(/2i2)')n,m write(*,*)n,m end $ gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050411/irun --enable-languages=c,f95 --host=i386-linux Thread model: posix gcc version 4.1.0 20050411 (experimental) $ gfortran pr17992.f && ./a.out 0 0
(In reply to comment #10) > Can you try with a later build and tell us what your exact source and output is? OK, now it is fixed! I had to wait one more week to get the new snapshot. Thank you very much. On top of this bug many others which I didn't report yet (I didn't know what was going on) are fixed.
(In reply to comment #11) > (In reply to comment #10) > > Can you try with a later build and tell us what your exact source and output is? > > OK, now it is fixed! I had to wait one more week to get the new snapshot. > Thank you very much. On top of this bug many others which I didn't report > yet (I didn't know what was going on) are fixed. But reopening as this is still needed for 4.0 like the other fortran bugs.
Subject: Bug 17992 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: tkoenig@gcc.gnu.org 2005-05-03 19:39:36 Modified files: libgfortran : ChangeLog libgfortran/io : transfer.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: eor_handling_1.f90 eor_handling_2.f90 eor_handling_3.f90 eor_handling_4.f90 eor_handling_5.f90 noadv_size.f90 pad_no.f90 Log message: 2005-05-03 Thomas Koenig <Thomas.Koenig@online.de> Backport from mainline: PR libfortran/17992 PR libfortran/19568 PR libfortran/19595 PR libfortran/20005 PR libfortran/20092 PR libfortran/20131 PR libfortran/20661 PR libfortran/20744 * io/transfer.c (top level): eor_condition: New static variable. (read_sf): Remove unnecessary zeroing of buffer (there is enough information in its length). Return a string of length 0 (to be padded by caller) if EOR was seen previously. Remove erroneous special casing of EOR for standard input. Set eor_condition for non-advancing I/O if an end of line was detected. Increment ioparm.size if necessary. (formatted_transfer): Skip the function if there is an EOR condition. (data_transfer_init): Initialize eor_condition to zero (false). (next_record_r): Clear sf_seen_eor if a \n has been seen already. (finalize_transfer): If there is an EOR condition, raise the error. 2005-05-03 Thomas Koenig <Thomas.Koenig@online.de> Backport from mainline: * eor_handling_1.f90: New test case. * eor_handling_2.f90: New test case. * eor_handling_3.f90: New test case. * eor_handling_4.f90: New test case. * eor_handling_5.f90: New test case. * noadv_size.f90: New test case. * pad_no.f90: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.22&r2=1.163.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.2&r2=1.32.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.156&r2=1.5084.2.157 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_5.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/noadv_size.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pad_no.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
Patch committed to 4.0.1. Fixed.