Bug 19155 - [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
[4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: libfortran
4.0.0
: P2 normal
: 4.0.2
Assigned To: Janne Blomqvist
http://gcc.gnu.org/ml/gcc-patches/201...
: patch
Depends on:
Blocks: 19292 21875
  Show dependency treegraph
 
Reported: 2004-12-25 21:46 UTC by Thomas Koenig
Modified: 2011-05-29 09:00 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-06-17 15:15:58


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2004-12-25 21:46:26 UTC
This is the NIST 110 failure, reduced.

$ cat blanks.f
      program blanks
      a = 42.
      open(19)
      write(19,'(A15)') 'E+00'
      rewind(19)
      read(19,'(E15.8)') a
      print *,a
      end
$ gfortran blanks.f
$ ./a.out
At line 6 of file blanks.f
Fortran runtime error: Bad value during floating point read
$ gfortran -v
Using built-in specs.
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041224 (experimental)

This is a regression from g77:
$ g77 blanks.f
$ ./a.out
  0.
Comment 1 Steve Kargl 2004-12-26 19:45:04 UTC
Looks like you've found a bug in g77, and if you're reduction of NIST's 110
test is correct, then NIST also has the same bug.   Here follows my digging
into this problem.

From the Fortran 77 standard (ansi-x3dot9-1978-Fortran77.pdf) 

  4.4.1 Basic Real Constant
  The form of a basic real constant is an optional sign, an integer part,
  a decimal point, and a fractional part, in that order.  Both the integer
  part and the fractional part are strings of digits; either of these parts
  may be omitted but not both.  A basic real constant may be written with
  more digits than a processor will use to approximate the value of the
  constant.  A basic real constant is interpreted as a decimal number.

  13.5.9 Numeric Editing
  The I, F, E, D, and G edit descriptors are used to specify input/output
  of integer, real, double precision, and complex data.  The following
  general rules apply:
    (1) On input, leading blanks are not significant.  The interpretation
        of blanks, other than leading blanks, is determined by a combination
        of any BLANK= specifier and any BN or BZ blank control that is
        currently in effect for the unit (13.5.8).  Plus signs may be omitted.
        A field of all blanks is considered to be zero.

It appears that the last sentence has been misinterpreted by g77 and NIST.
The wording from a May 2004 draft (04-007.pdf) of the newest standard is

   R416 signed-real-literal-constant
           is [ sign ] real-literal-constant
   R417 real-literal-constant
           is significand [ exponent-letter exponent ] [ kind-param ]
           or digit-string exponent-letter exponent [ kind-param ]
  R418 significand
           is digit-string . [ digit-string ]
           or . digit-string
  R419 exponent-letter
           is E
           or D
  R420 exponent
           is signed-digit-string

  10.6.1      Numeric editing
  The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to
  specify the input/output of integer, real, and complex data.  The
  following general rules apply:
    (1) On input, leading blanks are not significant.  When the input field
        is not an IEEE exceptional specification (10.6.1.2.1), the
        interpretation of blanks, other than leading blanks, is determined
        by the blank interpretation mode (10.7.6).  Plus signs may be omitted.
        A field containing only blanks is considered to be zero.

The first excerpt is the BNF of a real number.  The second excerpt contains
the same misinterpreted sentence.

So, your output of 'E+00' in not a valid real number under either F77 or F2003
(and most likely F95).  Secondly, the field you are reading is with the 
E15.8 format, which is 15 characters wide, and this field does not contain only
blanks because you wrote E+00 into it.

If you change "write(19,'(A15)') 'E+00'" to the obvious blank-filled field,
gfortran does the right thing: "write(19,'(A15)') '               '"

-- 
steve
Comment 2 Bud Davis 2005-01-16 23:45:32 UTC
added nist test to the title.
Comment 3 Francois-Xavier Coudert 2005-03-02 10:31:04 UTC
I agree with Steve's comment on this. As I am currently digging into the I/O
library, I need to know if it's worth working on this one. Knowing that many
commercial compilers (Intel, Portland, Sun) issue neither error nor warning and
read 0 into a, I think we may need to fix this (even if it's not a bug
standardwise).
Comment 4 Thomas Koenig 2005-03-11 21:21:43 UTC
My vote would go for "fixing" this, because of the NIST
testsuite failure.

Thomas
Comment 5 Steve Kargl 2005-03-11 22:33:42 UTC
My vote would be to fix the NIST test suite, which
has invalid code. ;-)  Gfortran is doing the right
thing.
Comment 6 Francois-Xavier Coudert 2005-03-31 16:38:39 UTC
Summary of what other compilers do: Portland, Sun and IBM accept it, while NEC
and MIPSpro reject it. My position would be: we go with the Standard.

Can we somehow have confirmation that Steve's interpretation is correct (not an
official interp, but maybe a well-advised opinion on comp.lang.fortran)?
Comment 7 kargl 2005-03-31 21:43:20 UTC
I posted a short question to c.l.f.
Comment 8 Francois-Xavier Coudert 2005-04-05 09:41:18 UTC
Well, the discussion on c.l.f. seems clear: the standard forbids this, but does
not require that we issue an error. It may be worth accepting it with a warning.
Comment 9 CVS Commits 2005-05-09 11:27:08 UTC
Subject: Bug 19155

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	fxcoudert@gcc.gnu.org	2005-05-09 11:21:02

Modified files:
	libgfortran/io : unix.c 
	libgfortran    : ChangeLog 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: pr19155.f 

Log message:
	PR libfortran/19155
	* io/read.c (read_f): Accept 'e', 'E', 'd' and 'D' as first
	non-blank characters of a real number.
	* gfortran.dg/pr19155.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.22&r2=1.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.208&r2=1.209
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5448&r2=1.5449
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19155.f.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 10 CVS Commits 2005-05-09 11:31:50 UTC
Subject: Bug 19155

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	fxcoudert@gcc.gnu.org	2005-05-09 11:27:06

Modified files:
	gcc/testsuite  : ChangeLog 
	libgfortran    : ChangeLog 
	libgfortran/io : read.c 
Added files:
	gcc/testsuite/gfortran.dg: pr19155.f 

Log message:
	PR libfortran/19155
	* io/read.c (read_f): Accept 'e', 'E', 'd' and 'D' as first
	non-blank characters of a real number.
	* gfortran.dg/pr19155.f: New test.

Patches:
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.166&r2=1.5084.2.167
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19155.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
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.24&r2=1.163.2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.10.1

Comment 11 Francois-Xavier Coudert 2005-05-09 11:37:00 UTC
I don't close this one since NIST test FM110 is not fixed with this patch.
Comment 12 Andrew Pinski 2005-05-09 21:38:12 UTC
Confirmed.
Comment 13 David Edelsohn 2005-05-16 19:45:52 UTC
The testcase pr19155.f fails on AIX.  I am confused if this is suppose to work
after the patch or not.  Either the testcase should be XFAILed or something else
is wrong with the patch.
Comment 14 Francois-Xavier Coudert 2005-05-16 20:19:10 UTC
Testcase pr19155.f does not fail on i386-linux, i686-freebsd and sparc-solaris.
With the patch committed, it is supposed to work. Can you investigate further
(compile the testcase manually and see why it fails)? I don't have access to a
AIX machine.
Comment 15 Francois-Xavier Coudert 2005-06-12 08:05:11 UTC
NIST test FM110 is still failing, and here is the reduced testcase:

$ cat FM110.f 
      real a
      character*80 c
      c = "+          "
      read (c,"(F11.4)") a
      print *, a
      end
$ g77 FM110.f && ./a.out                            
  0.
$ gfortran FM110.f && ./a.out 
At line 4 of file FM110.f
Fortran runtime error: Bad value during floating point read
Comment 16 Francois-Xavier Coudert 2005-06-12 09:21:42 UTC
(In reply to comment #15)
> NIST test FM110 is still failing, and here is the reduced testcase:

Proposed patch for this problem: http://gcc.gnu.org/ml/fortran/2005-06/msg00240.html
Comment 17 kargl 2005-06-12 17:48:19 UTC
Sigh.  I really, really, detest these special cases of "E+00" and "+  ",
which violate the Fortran 95 standard.  But, g77 appears to accept
both. :-(

OK for mainline. :-(
Comment 18 CVS Commits 2005-06-12 19:59:23 UTC
Subject: Bug 19155

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	fxcoudert@gcc.gnu.org	2005-06-12 19:59:17

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gfortran.dg: pr19155.f 
	libgfortran    : ChangeLog 
	libgfortran/io : read.c 

Log message:
	PR libfortran/19155
	* io/read.c (read_f): Take care of spaces after initial sign.
	* gfortran.dg/pr19155.f: Add test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5626&r2=1.5627
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr19155.f.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.235&r2=1.236
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&r1=1.9&r2=1.10

Comment 19 Francois-Xavier Coudert 2005-06-12 20:05:08 UTC
Fixed on mainline, waiting for 4.0 to reopen. With that patch, FM110 no longer
fails. One less in NIST testsuite.

As for comment 13 (testcase failure on AIX), I'm waiting for additional feedback.
Comment 21 Francois-Xavier Coudert 2005-06-16 23:03:22 UTC
Added dje@gcc.gnu.org in Cc list and marked as waiting for feedback.
Comment 22 David Edelsohn 2005-06-17 15:15:57 UTC
pr19155.f produces the following error output:

At line 13 of file pr19155.f
Fortran runtime error: Range error during floating point read

AIX strtod ("", NULL) sets errno to EINVAL, as allowed by the standard ("may 
be set"); Linux and *BSD do not.  libgfortran does not expect errno to be set.
Comment 23 Francois-Xavier Coudert 2005-06-17 15:40:10 UTC
Keeping the patch keyword and changing the patch URL, here is the fix for that
new bug: http://gcc.gnu.org/ml/fortran/2005-06/msg00240.html
Comment 24 CVS Commits 2005-06-17 16:20:53 UTC
Subject: Bug 19155

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	fxcoudert@gcc.gnu.org	2005-06-17 16:20:30

Modified files:
	libgfortran    : ChangeLog 
	libgfortran/io : read.c 

Log message:
	PR libfortran/19155
	* io/read.c (convert_real): strtod can set errno to EINVAL on an
	empty string, but we shouldn't have an error in that case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.245&r2=1.246
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&r1=1.10&r2=1.11

Comment 25 CVS Commits 2005-06-17 16:24:13 UTC
Subject: Bug 19155

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	fxcoudert@gcc.gnu.org	2005-06-17 16:23:42

Modified files:
	libgfortran    : ChangeLog 
	libgfortran/io : read.c 

Log message:
	PR libfortran/19155
	* io/read.c (convert_real): strtod can set errno to EINVAL on an
	empty string, but we shouldn't have an error in that 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.54&r2=1.163.2.55
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8.10.2&r2=1.8.10.3

Comment 26 Francois-Xavier Coudert 2005-06-17 16:24:52 UTC
Closed.
Comment 27 Janne Blomqvist 2011-05-28 08:22:14 UTC
Reopening, since the EINVAL thing is causing problems on HP-UX 11.31. Assigning to myself, patch at http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02224.html
Comment 28 Janne Blomqvist 2011-05-29 08:59:47 UTC
Author: jb
Date: Sun May 29 08:59:44 2011
New Revision: 174393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174393
Log:
PR 19155 Check for strtod failure via endptr

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/read.c
Comment 29 Janne Blomqvist 2011-05-29 09:00:37 UTC
Closing, fixed.