Bug 17992 - [4.0 only] reading empty line does not return 0
Summary: [4.0 only] reading empty line does not return 0
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.1
Assignee: Not yet assigned to anyone
URL:
Keywords: patch
Depends on:
Blocks: 19292
  Show dependency treegraph
 
Reported: 2004-10-14 07:09 UTC by milan
Modified: 2005-05-03 19:51 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.1.0
Known to fail:
Last reconfirmed: 2004-12-23 04:07:27


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description milan 2004-10-14 07:09:25 UTC
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.
Comment 1 Bud Davis 2004-12-23 04:07:55 UTC
i concur, it is a libgfortran bug.
Comment 2 Bud Davis 2004-12-23 04:23:36 UTC
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

 
Comment 3 milan 2005-01-06 23:16:22 UTC
> 
> 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.

Comment 4 Francois-Xavier Coudert 2005-02-25 19:50:27 UTC
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).
Comment 5 GCC Commits 2005-04-10 08:36:04 UTC
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

Comment 6 Thomas Koenig 2005-04-10 08:37:17 UTC
Fixed in 4.1.0, waiting for inclusion into 4.0.
Comment 7 milan 2005-04-11 00:46:20 UTC
(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?
Comment 8 Andrew Pinski 2005-04-11 00:51:02 UTC
(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.
Comment 9 milan 2005-04-11 01:58:41 UTC
(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.

Comment 10 Francois-Xavier Coudert 2005-04-11 08:01:02 UTC
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
Comment 11 milan 2005-04-20 01:10:14 UTC
(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.
Comment 12 Andrew Pinski 2005-04-20 01:15:02 UTC
(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.
Comment 13 GCC Commits 2005-05-03 19:40:06 UTC
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

Comment 14 Thomas Koenig 2005-05-03 19:49:14 UTC
Patch committed to 4.0.1.  Fixed.
Comment 15 Thomas Koenig 2005-05-03 19:51:54 UTC
Patch committed to 4.0.1.  Fixed.