[Bug fortran/78351] New: comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] New: comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

            Bug ID: 78351
           Summary: comma not terminating READ of formatted input field -
                    ok in 4.1.7, not 4.4.7- maybe related to 25419?
           Product: gcc
           Version: 4.4.7
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kevin.b.beard at nasa dot gov
  Target Milestone: ---

Created attachment 40038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40038&action=edit
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I will investigate.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-11-14
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed from 4.8 up to trunk (7.0).
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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?  Also, "-std=legacy" doesn't help.   It
is difficult to modify many millions of lines of legacy code to change that.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Nov 15, 2016 at 11:21:05PM +0000, 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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

Jerry DeLisle <jvdelisle at gcc dot gnu.org> 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 <jvdelisle at gcc dot gnu.org> ---
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?
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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).
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #12 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
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
[hidden email]
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 [[hidden email]]
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 <jvdelisle at gcc dot gnu.org> 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 <jvdelisle at gcc dot gnu.org> ---
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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
[hidden email]
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 [[hidden email]]
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Try to find what you want in http://www.fortran.com/F77_std/rjcnf0001.html.
Good luck!
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
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.
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #17 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
Hi,

    Many thanks to Jerry DeLisle ‎[[hidden email]]‎; 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
[hidden email]
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 [[hidden email]]
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 <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.

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
=
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #18 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
Created attachment 40061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40061&action=edit
x2.dat
Reply | Threaded
Open this post in threaded view
|

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

segher at gcc dot gnu.org
In reply to this post by segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Nov 17, 2016 at 12:43:40AM +0000, kevin.b.beard at nasa dot gov wrote:
>     Many thanks to Jerry DeLisle [[hidden email]]; 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.
12