https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #13 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
Hi,
Thanks for looking at this. I'm sorry to say I don't have access to the
official F77 standards,
perhaps you could send me a copy of the whole? The section you quoted doesn't
seems to
to exclude the comma-terminated behavior I've always seen, and it has been
widely used
by many many programmers throughout the community over the years.
I've always been told and believed that a comma terminated a numeric field; but
w/o
access to the standards I can't point to the line that says it must.
What I'd like to see is that is that newer gfortran versions support its
previous (and every
other FORTRAN compiler I've tested) behavior.
The flag "-std=legacy" does not restore the previous behavior, and I've found
no option
in the newer gfortrans that does.
$> cat x1.f
character*80 s
s= '1,2,3,,,,'
READ(s,'(2i10)') i,j
write(6,'(2i10)') i,j
end
$> gfortran --version
GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
$> gfortran -std=legacy -o x1 x1.f
$> ./x1
At line 3 of file x1.f
Fortran runtime error: Bad value during integer read
vs:
$> gfortran ---version
GNU Fortran (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
Copyright (C) 2007 Free Software Foundation, Inc.
$> gfortran -o x1 x1.f
$> ./x1
1 2
$> g77 --version
GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4.1)
Copyright (C) 2006 Free Software Foundation, Inc.
$> g77 -o x1_g77 x1.f
$> ./x1_g77
1 2
$> ifort --version
ifort (IFORT) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation. All rights reserved.
$> ifort -o x1_ifort x1.f
$> ./x1_ifort
1 2
What I'd like to see is to restore gfortran's previous behavior that
it's had since it came out.
Thanks again for looking into this,
Kevin
----------------------------------------------------------
Dr. Kevin B. Beard, Lockheed Martin Corporation
kevin.b.be...@nasa.gov
281-244-8534
room 548C, building 45, NASA Johnson Space Center
US Mail: Kevin B. Beard, bldg 45, mail code Wyle/OPS/45, P.O.Box 58487,
Houston, TX 77258
________________________________________
From: sgk at troutmask dot apl.washington.edu [gcc-bugzi...@gcc.gnu.org]
Sent: Tuesday, November 15, 2016 6:06 PM
To: Beard, Kevin B. (JSC-SD2)[WYLE LABORATORIES, INC.]
Subject: [Bug fortran/78351] comma not terminating READ of formatted input
field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Nov 15, 2016 at 10:51:41PM +0000, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> --- Comment #5 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
> I've always understood that a comma will terminate a FORTRAN field - for
> example:
>
> https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.html
>
> Am I misunderstanding the F77 standard?
Yes. If you read the text at the above URL, you find "The I/O system
is just being more lenient than described in the FORTRAN Standard."
The Fortran 77 standard contains
13.2.1 Edit Descriptors
An edit descriptor is either a repeatable edit descriptor or
a nonrepeatable edit descriptor.
The forms of a repeatable edit descriptor are:
Iw
Iw.m
...
where:
I, F, E, D, G, L, and A indicate the manner of editing
w and e are nonzero, unsigned, integer constants
d and m are unsigned integer constants
13.5 Editing
A field is a part of a record that is read on input or written
on output when format control processes one I, F, E, D, G, L,
A, H, or apostrophe edit descriptor. The field width is the
size in characters of the field.
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.
(2) On input, with F, E, D, and G editing, a decimal point
appearing in the input field overrides the portion of an edit
descriptor that specifies the decimal point location. The input
field may have more digits than the processor uses to approximate
the value of the datum.
(3) On output, ...
(4) On output, ...
(5) On output, ...
13.5.9.1 Integer Editing
The Iw and Iw.m edit descriptors indicate that the field to be
edited occupies w positions. The specified input/output list item
must be of type integer. On input, the specified list item will
become defined with an integer datum. On output, the specified list
item must be defined with an integer datum.
On input, an Iw.m edit descriptor is treated identically to an Iw
edit descriptor.
In the input field, the character string must be in the form of an
optionally signed integer constant, except for the interpretation
of blanks (13.5.9, item (1)).
I can find no place that states a comma delimits formatted input.
> Also, "-std=legacy" doesn't help. It is difficult to modify
> many millions of lines of legacy code to change that.
I don't understand your point here. -std=legacy would allow the
non-standard behaviour. You would simply need to add -std=legacy
to your command line. No modifications to the many millions of
lines of legacy code are required.
It seems that you're suggesting that gfortran should simply
implement Oracle's compiler behavior and silently accept the
non-standard input. This is exactly how you got into your
current situation. Instead of programming to the standard,
programmers wrote code accepted by whatever the compiler of
the dayi accepted.
--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
