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.
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
added nist test to the title.
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).
My vote would go for "fixing" this, because of the NIST testsuite failure. Thomas
My vote would be to fix the NIST test suite, which has invalid code. ;-) Gfortran is doing the right thing.
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)?
I posted a short question to c.l.f.
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.
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
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
I don't close this one since NIST test FM110 is not fixed with this patch.
Confirmed.
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.
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.
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
(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
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. :-(
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
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.
Subject: Bug 19155 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: fxcoudert@gcc.gnu.org 2005-06-16 22:39:10 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&only_with_tag=gcc-4_0-branch&r1=1.5084.2.240&r2=1.5084.2.241 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=1.1.2.1&r2=1.1.2.2 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.52&r2=1.163.2.53 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.1&r2=1.8.10.2
Added dje@gcc.gnu.org in Cc list and marked as waiting for feedback.
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.
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
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
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
Closed.
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
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
Closing, fixed.