This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
fortran/4722: f77 0.5.26 handles EOF in scratch files incorrectly, f77 0.5.25 is OK
- To: gcc-gnats at gcc dot gnu dot org
- Subject: fortran/4722: f77 0.5.26 handles EOF in scratch files incorrectly, f77 0.5.25 is OK
- From: arends at nlr dot nl
- Date: 28 Oct 2001 20:51:09 -0000
- Cc: merazzi at smr dot ch
- Reply-To: arends at nlr dot nl
>Number: 4722
>Category: fortran
>Synopsis: f77 0.5.26 handles EOF in scratch files incorrectly, f77 0.5.25 is OK
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Oct 28 12:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Paul Arendsen
>Release: unknown-1.0
>Organization:
>Environment:
Linux IA32 (RedHat 7.1)
>Description:
f77 0.5.26 is used in Redhat 7.1 incorrectly handles scratch
files, while it is being treated OK using f77 0.5.25 as in
SuSe 7.2. The incorrect handling occurs when the end of file
(EOF) is reached.
Compile attached file " g77 tt.f -o tt.x"
run tt.x and and should get
1
2
3
end of file
The 0.5.26 version gives
1
2
3
error in file
Hence incorrect handling when the end of file
has been reached. For me developing Finite Element
software (mostly Fortran and some C) this is
quite unpleasant.
>How-To-Repeat:
Compile and run attached file one should get
1
2
3
end of file
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="tt.f"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tt.f"
YzIzNDU2NwogICAgICBwcm9ncmFtIHR0CiAgICAgIGludGVnZXIgaQogCiAgICAgIG9wZW4gKDEs
YWNjZXNzPSdzZXF1ZW50aWFsJyxmb3JtPSd1bmZvcm1hdHRlZCcsCiAgICAgKiAgICAgICBzdGF0
dXM9J3NjcmF0Y2gnKQogCiAgICAgIGRvIGk9MSwzCiAgICAgIHdyaXRlKDEpIGkKICAgICAgZW5k
ZG8KICAgICAgcmV3aW5kICgxKQogCjEwICAgIHJlYWQoMSxlcnI9OTAwLGVuZD04MDApIGkKNTAg
ICAgZm9ybWF0KGkzKQogICAgICBwcmludCosaQogICAgICBnb3RvIDEwCiAKODAwICAgY29udGlu
dWUKICAgICAgcHJpbnQqLCJlbmQgb2YgZmlsZSIKICAgICAgZ290byAxMDAwCiAKOTAwICAgY29u
dGludWUKICAgICAgcHJpbnQqLCJlcnJvciBpbiBmaWxlIgogCjEwMDAgIGNvbnRpbnVlCiAgICAg
IGVuZAo=