[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 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Jerry DeLisle --- Even after getting the patch into gcc 7 I still get a failure in the test case. I suspect some other patch not previously applied to 7 is involved. I do not think this is worth pursuing further so I an closing.
[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 Jerry DeLisle changed: What|Removed |Added Last reconfirmed|2016-11-14 00:00:00 |2018-11-19 Known to work||8.2.1, 9.0 --- Comment #28 from Jerry DeLisle --- I am not getting a clean patch apply to gcc-7-branch yet. Updated known to work.
[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 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #27 from Martin Liška --- Jerry: Can you please update Known to work?
[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 #26 from Jerry DeLisle --- Author: jvdelisle Date: Fri Nov 9 17:29:33 2018 New Revision: 265979 URL: https://gcc.gnu.org/viewcvs?rev=265979=gcc=rev Log: 2018-11-09 Jerry DeLisle PR libfortran/78351 * io/transfer.c (read_sf_internal): Delete leftover debug code. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[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 #25 from Jerry DeLisle --- Author: jvdelisle Date: Fri Nov 9 17:07:39 2018 New Revision: 265976 URL: https://gcc.gnu.org/viewcvs?rev=265976=gcc=rev Log: 2018-11-09 Jerry DeLisle Backport from trunk PR libfortran/78351 * io/transfer.c (read_sf_internal): Add support for early comma termination of internal unit formatted reads. Backported from mainline PR libfortran/78351 * gfortran.dg/read_legacy_comma.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/read_legacy_comma.f90 Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/io/transfer.c
[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 #24 from Jerry DeLisle --- Author: jvdelisle Date: Fri Nov 9 02:46:03 2018 New Revision: 265946 URL: https://gcc.gnu.org/viewcvs?rev=265946=gcc=rev Log: 2018-11-08 Jerry DeLisle PR libfortran/78351 * io/transfer.c (read_sf_internal): Add support for early comma termination of internal unit formatted reads. * gfortran.dg/read_legacy_comma.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/read_legacy_comma.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[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 #23 from Jerry DeLisle --- Final patch submitted for review. https://gcc.gnu.org/ml/fortran/2018-11/msg00017.html
[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 #22 from Jerry DeLisle --- Created attachment 44837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44837=edit Preliminary Patch The attached patch appears to fix this. I am thinking about not doing the check if -std=f95,f2003,f2008. If performance is not a big issue, we can leave it as is. The braces around the new block of code gets rid of a bogus warning about *p not being initialized.
[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 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW
[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 #21 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #19)
> On Thu, Nov 17, 2016 at 12:43:40AM +, kevin.b.beard at nasa dot gov
> wrote:
> > Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize
> > that an internal record is now not treated the same as an external record!
>
> Ugh. It ought to be treated the same.
>
Working on it. In read_sf we have this:
/* Short circuit the read if a comma is found during numeric input.
The flag is set to zero during character reads so that commas in
strings are not ignored */
else if (q == ',')
if (dtp->u.p.sf_read_comma == 1)
{
seen_comma = 1;
notify_std (>common, GFC_STD_GNU,
"Comma in formatted numeric read.");
break;
}
and it does give an error when using -std=f95. No such code for
read_internal_sf.
[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 #20 from Steve Kargl --- On Thu, Nov 17, 2016 at 01:44:45AM +, sgk at troutmask dot apl.washington.edu wrote: > > In the above, you are hitting an end-of-record. I would need > to go read the Standard to see what happens in this situation. > I suspect that this may be Standard conforming, but the variables > i and j are undefined and technically cannot be referenced until > the variables become defined. The acceptance of comma is a pox upon the world. The following should simply exit upon execution, instead prints ' 12' program foo open(unit=10, file='zxc') read(10, '(2I10)', eor=3, advance='no') i,j print *, i, j stop 3 continue end program foo where the file 'zxc' contains the line 1,2,3 gfortran is definitely doing the right thing with your original code. Using Fortran ability to report errors shows program foo integer k character(len=80) s, t s = '1,2,3' read(s, '(2I10)', err=3, iostat=k, iomsg=t) i,j print *, i, j stop 3 continue print *, k, trim(t) end program foo % gfc7 -o z c.f90 % ./z 5010 Bad value during integer read
[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 #19 from Steve Kargl --- On Thu, Nov 17, 2016 at 12:43:40AM +, kevin.b.beard at nasa dot gov wrote: > Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize > that an internal record is now not treated the same as an external record! Ugh. It ought to be treated the same. > I didn't think of that. > > In the attached example, you see "1,2,3" read from a file with > > READ(1,'(2i10)') i,j > > DOES still work in gfortran 4.4.7, but This is a bug that needs to be fixed. > READ(1,'(a)') line > READ(line,'(2i10)') i,j > > does NOT. Standard conforming behavior as I have now pointed out in 3 posts. > If one parses the string appropriately and reads > it one part of a time, it does work: > > READ(line(1:1),'(i10)') i > READ(line(3:3),'(i10)') j In the above, you are hitting an end-of-record. I would need to go read the Standard to see what happens in this situation. I suspect that this may be Standard conforming, but the variables i and j are undefined and technically cannot be referenced until the variables become defined.
[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 #17 from Dr. Kevin B. Beard --- Hi, Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize that an internal record is now not treated the same as an external record! I didn't think of that. In the attached example, you see "1,2,3" read from a file with READ(1,'(2i10)') i,j DOES still work in gfortran 4.4.7, but READ(1,'(a)') line READ(line,'(2i10)') i,j does NOT. If one parses the string appropriately and reads it one part of a time, it does work: READ(line(1:1),'(i10)') i READ(line(3:3),'(i10)') j A workaround via an option would be great; better would be to have internal and external records READ the same way again. Thanks again for all your help, 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: Wednesday, November 16, 2016 1:25 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 #16 from Steve Kargl --- On Wed, Nov 16, 2016 at 06:36:58PM +, kevin.b.beard at nasa dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 > > --- Comment #13 from Dr. Kevin B. Beard --- > 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? google "F77 standard" https://www.fortran.com/F77_std/rjcnf0001.html https://gcc.gnu.org/wiki/GFortranStandards > The section you quoted doesn't seems too 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 cited the entire relevant passage. Now, edited to its essences. 13.5.9.1 Integer Editing The Iw and Iw.m edit descriptors indicate that the field to be edited occupies w positions. 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)). In your code, you have character*80 s s= '1,2,3' READ(s,'(2i10)') i,j The format request a field width of 10 for 'i'. So, 10 positions in 's' are '1,2,3 ' (where I had to add a space because technically 's' does not have 10 positions). A signed integer constant does not contain 5 commas. > I've always been told and believed that a comma terminated a > numeric field; For list-directed input (i.e., FMT=*), yes, a comma is a value separator. > but w/o > access to the standards I can't point to the line that > says it must. You won't find a line. I cited the entire relevant text from Fortran 77 that applies to the above code. You either need to change the code to character*80 s ! 12345678901234567890 s= '1 2 ' READ(s,'(2i10)') i,j where '1' can appear anywhere within the first 10 positions, or character*80 s ! 12345678901234567890 s= '1,2,3' READ(s,*) i,j > What I'd like to see is that newer gfortran versions support > its previous (and every other FORTRAN compiler I've tested) > behavior. So, no bugs should ever be fixed? Have you filed bug reports with all the other vendors? I suspect that if you use an option with those vendors' compiler to request Standard conformance, you'll find that the code is invalid. If not, file a bug report with those vendors. > The flag "-std=legacy" does not restore the previous behavior, > and I've found no option in the newer gfortrans that does. That's because no one has implemented the patch to (un)fix gfortran to handle invalid code. jerryd has indicated that he'll look into the issue. I do find it ironic that you refuse to fix broken code, but expect those that strive to provide a quality tool like gfortran to break its conformance to the standard. -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug. =
[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 #18 from Dr. Kevin B. Beard --- Created attachment 40061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40061=edit x2.dat
[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 #16 from Steve Kargl --- On Wed, Nov 16, 2016 at 06:36:58PM +, kevin.b.beard at nasa dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 > > --- Comment #13 from Dr. Kevin B. Beard --- > 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? google "F77 standard" https://www.fortran.com/F77_std/rjcnf0001.html https://gcc.gnu.org/wiki/GFortranStandards > The section you quoted doesn't seems too 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 cited the entire relevant passage. Now, edited to its essences. 13.5.9.1 Integer Editing The Iw and Iw.m edit descriptors indicate that the field to be edited occupies w positions. 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)). In your code, you have character*80 s s= '1,2,3' READ(s,'(2i10)') i,j The format request a field width of 10 for 'i'. So, 10 positions in 's' are '1,2,3 ' (where I had to add a space because technically 's' does not have 10 positions). A signed integer constant does not contain 5 commas. > I've always been told and believed that a comma terminated a > numeric field; For list-directed input (i.e., FMT=*), yes, a comma is a value separator. > but w/o > access to the standards I can't point to the line that > says it must. You won't find a line. I cited the entire relevant text from Fortran 77 that applies to the above code. You either need to change the code to character*80 s ! 12345678901234567890 s= '1 2 ' READ(s,'(2i10)') i,j where '1' can appear anywhere within the first 10 positions, or character*80 s ! 12345678901234567890 s= '1,2,3' READ(s,*) i,j > What I'd like to see is that newer gfortran versions support > its previous (and every other FORTRAN compiler I've tested) > behavior. So, no bugs should ever be fixed? Have you filed bug reports with all the other vendors? I suspect that if you use an option with those vendors' compiler to request Standard conformance, you'll find that the code is invalid. If not, file a bug report with those vendors. > The flag "-std=legacy" does not restore the previous behavior, > and I've found no option in the newer gfortrans that does. That's because no one has implemented the patch to (un)fix gfortran to handle invalid code. jerryd has indicated that he'll look into the issue. I do find it ironic that you refuse to fix broken code, but expect those that strive to provide a quality tool like gfortran to break its conformance to the standard.
[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 #15 from Jerry DeLisle --- Well, on further investigation I see that we do have a flag in read_sf to signal a comma. It does not have this flag in read_sf_internal, So definitely does not work on strings. My bet is that when we/I split the function, way way back, I did not carry over the comma checks in order to get performance with internal units. I plan to test on a file and make sure this is working then I will see if I can do something on internal units that does not penalize too much.
[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 #14 from Dominique d'Humieres --- Try to find what you want in http://www.fortran.com/F77_std/rjcnf0001.html. Good luck!
[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 #13 from Dr. Kevin B. Beard --- 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 --- On Tue, Nov 15, 2016 at 10:51:41PM +, 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 --- > 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
[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 #12 from Dr. Kevin B. Beard --- Hi, Generally our (NASA's) legacy FORTRAN's READ's use no special flags (IOSTAT=, ERR=, END=, etc.). We have a huge amount of code going back to the early 1960's; some is an eclectic mixture of FORTRAN IV, 66, 77, and 90. I have always been told (and seen) that since 77 a comma terminates a field properly - I don't have a copy of the actual standards documents (https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.html) I try to avoid FMT=* because it often gives problems when different compilers are used. Thanks, 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: jvdelisle at gcc dot gnu.org [gcc-bugzi...@gcc.gnu.org] Sent: Tuesday, November 15, 2016 6:36 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 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #9 from Jerry DeLisle --- Two things going on here. First, Looking at read_decimal in read.c way back on the 4.1 branch, we did nothing special other than generate an error and return. Same code we have now. So we never tried to interpret the comma uniquely. We are getting a segfault right after the error and the backtrace is landing in the middle of read_block_direct, so the error recovery is broken. Segfault is never acceptable so I will fix that first. (error recovery) By any chance do your data streams have the data padded with spaces such that they do not violate the format width specifier? Do your actual read statements also have the END= or EOR= specifiers? -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
[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 #11 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #10) > > We are getting a segfault right after the error and the backtrace > > is landing in the middle of read_block_direct, so the error recovery > > is broken. Segfault is never acceptable so I will fix that first. > > (error recovery) > > I don't see that: > > [Book15] f90/bug% gfc pr78351.f90 -fno-backtrace > [Book15] f90/bug% ./a.out > At line 3 of file pr78351.f90 > Fortran runtime error: Bad value during integer read > > Note that trunk (7.0) behaves as gcc 4.3.1 (the oldest version I have). Agree, I was single stepping through with gdb and it was misleading me on the trail. I was probably using symbols from 4.6 on my system. On to the comma question.
[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 #10 from Dominique d'Humieres --- > We are getting a segfault right after the error and the backtrace > is landing in the middle of read_block_direct, so the error recovery > is broken. Segfault is never acceptable so I will fix that first. > (error recovery) I don't see that: [Book15] f90/bug% gfc pr78351.f90 -fno-backtrace [Book15] f90/bug% ./a.out At line 3 of file pr78351.f90 Fortran runtime error: Bad value during integer read Note that trunk (7.0) behaves as gcc 4.3.1 (the oldest version I have).
[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 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #9 from Jerry DeLisle --- Two things going on here. First, Looking at read_decimal in read.c way back on the 4.1 branch, we did nothing special other than generate an error and return. Same code we have now. So we never tried to interpret the comma uniquely. We are getting a segfault right after the error and the backtrace is landing in the middle of read_block_direct, so the error recovery is broken. Segfault is never acceptable so I will fix that first. (error recovery) By any chance do your data streams have the data padded with spaces such that they do not violate the format width specifier? Do your actual read statements also have the END= or EOR= specifiers?
[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 #8 from Steve Kargl --- On Tue, Nov 15, 2016 at 11:21:05PM +, jvdelisle at gcc dot gnu.org wrote: > > I just finished fixing another issue and am now looking at this one. Generally > speaking if code worked before under g77, we do our best to have it work under > gfortran with -std=gnu which is the default, then if something violates f95 or > later we will give error with -std=f95. I will post back here what I determine > as far as what the bug specifically is. > With 15 years of hindsight, I think that the decision to support whatever g77 supported may have been a mistake. The nonstandard behavior, that is the subject of this PR, also violates the F66 standard. PS: I think -std=f2008 should be gfortran's default, and all of the nonstandards hidden behind -std=legacy.
[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 --- On Tue, Nov 15, 2016 at 10:51:41PM +, 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 --- > 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.
[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 #6 from Jerry DeLisle --- (In reply to Dr. Kevin B. Beard from comment #5) > 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? Also, "-std=legacy" doesn't help. > It is difficult to modify many millions of lines of legacy code to change > that. I just finished fixing another issue and am now looking at this one. Generally speaking if code worked before under g77, we do our best to have it work under gfortran with -std=gnu which is the default, then if something violates f95 or later we will give error with -std=f95. I will post back here what I determine as far as what the bug specifically is.
[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 #5 from Dr. Kevin B. Beard --- 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? Also, "-std=legacy" doesn't help. It is difficult to modify many millions of lines of legacy code to change that.
[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 #4 from jvdelisle at charter dot net ---
On 11/14/2016 11:09 AM, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> kargl at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> CC||kargl at gcc dot gnu.org
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Dr. Kevin B. Beard from comment #0)
>> Created attachment 40038 [details]
>> Simple example - comma no longer a format field delimiter - gfortran 4.1.2
>> ok, 4.4.7- fails
>>
>> Here @ NASA we often have strings to read of the form:
>>
>> #,#,#,#,.
>>
>> and on many platforms, gfortran 4.1.2 and (most?) earlier, Intel Fortran
>> 16.0.3, g77-3.4.6 and most other FORTRANs, it would treat the "," as a field
>> delimiter during a formatted READ - for example (x1.f):
>>
>> character*80 s
>> s= '1,2,3'
>> READ(s,'(2i10)') i,j
>> write(6,'(2i10)') i,j
>> end
>>
>> would print " 1 2".
>>
>> However, 4.4.7 ("gfortran -o x1 x1.f") now (11/2016) fails with
>>
>> "Fortran runtime error: Bad value during integer read".
>>
>> I believe it worked with 4.4.7 back in 9/2016 on ScientificLinux-6.4 fine,
>> but there have been security patches done since then. It also fails on
>> 4.8.5 and 5.3.0 under Red Hat Enterprise Linux Server release 5.11 It would
>> be very nice to be able to restore the old behavior.
>>
>> This may be related to bug#25519.
>
> gfortran's behavior conforms to the standard while your code
> does not conform. Perhaps, gfortran should accept a comma as
> a field delimiter under -std=legacy, but preference should
> be to fixing the wrong code.
>
> 10.7.2.2 Integer editing
>
> The Iw and Iw.m edit descriptors indicate that the field to be
> edited occupies w positions, except when w is zero. When w is
> zero, the processor selects the field width. On input, w shall
> not be zero. The specified input/output list item shall be of
> type integer. ...
>
> On input, m has no effect.
>
> In the input field for the I edit descriptor, the character string
> shall be a signed-digit-string (R409), except for the interpretation
> of blanks.
>
> R409 signed-digit-string is [ sign ] digit-string
> R410 digit-string
> R411 sign is digit [ digit ] ...
>
> is +
> or
>
>
> Perhaps, you want list-directed formatting
>
> 10.10 List-directed formatting
>
> 10.10.1 General
>
> List-directed input/output allows data editing according to the type
> of the list item instead of by a format specification. It also allows
> data to be free-field, that is, separated by commas (or semicolons) or
> blanks.
>
Thank you for that clarification. That makes it not a regression really, just
an
enhancement.
Jerry
[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
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Dr. Kevin B. Beard from comment #0)
> Created attachment 40038 [details]
> Simple example - comma no longer a format field delimiter - gfortran 4.1.2
> ok, 4.4.7- fails
>
> Here @ NASA we often have strings to read of the form:
>
> #,#,#,#,.
>
> and on many platforms, gfortran 4.1.2 and (most?) earlier, Intel Fortran
> 16.0.3, g77-3.4.6 and most other FORTRANs, it would treat the "," as a field
> delimiter during a formatted READ - for example (x1.f):
>
> character*80 s
> s= '1,2,3'
> READ(s,'(2i10)') i,j
> write(6,'(2i10)') i,j
> end
>
> would print " 1 2".
>
> However, 4.4.7 ("gfortran -o x1 x1.f") now (11/2016) fails with
>
> "Fortran runtime error: Bad value during integer read".
>
> I believe it worked with 4.4.7 back in 9/2016 on ScientificLinux-6.4 fine,
> but there have been security patches done since then. It also fails on
> 4.8.5 and 5.3.0 under Red Hat Enterprise Linux Server release 5.11 It would
> be very nice to be able to restore the old behavior.
>
> This may be related to bug#25519.
gfortran's behavior conforms to the standard while your code
does not conform. Perhaps, gfortran should accept a comma as
a field delimiter under -std=legacy, but preference should
be to fixing the wrong code.
10.7.2.2 Integer editing
The Iw and Iw.m edit descriptors indicate that the field to be
edited occupies w positions, except when w is zero. When w is
zero, the processor selects the field width. On input, w shall
not be zero. The specified input/output list item shall be of
type integer. ...
On input, m has no effect.
In the input field for the I edit descriptor, the character string
shall be a signed-digit-string (R409), except for the interpretation
of blanks.
R409 signed-digit-string is [ sign ] digit-string
R410 digit-string
R411 sign is digit [ digit ] ...
is +
or
Perhaps, you want list-directed formatting
10.10 List-directed formatting
10.10.1 General
List-directed input/output allows data editing according to the type
of the list item instead of by a format specification. It also allows
data to be free-field, that is, separated by commas (or semicolons) or
blanks.
[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 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0).
[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 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I will investigate.
