https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, Nov 16, 2016 at 06:36:58PM +0000, 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 <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? 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.
