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