This is the mail archive of the
mailing list for the GCC project.
Re: [patch, libfortran] Handle missing EOR marker when reading
- From: Tobias Burnus <burnus at net-b dot de>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 06 Feb 2010 10:11:06 +0100
- Subject: Re: [patch, libfortran] Handle missing EOR marker when reading
- References: <4B6D0A8F.firstname.lastname@example.org>
Jerry DeLisle wrote:
> After reviewing the F2003 standard and the relevant clauses I am
> convinced that the standard is not "silent" on this case mentioned in
> the thread.
I disagree: The standard does not clearly say how a record marker looks
like and keeps other things as implementation defined. However, I think
your interpretation is a sensible extension of the standard into the
> Summarizing the case, the input file contains:
> GFortran currently does the following:
> IOSTAT_EOR(-2), Zero (0), IOSTAT_END(-1)
> I believe this is wrong
I think the ZERO is really unexpected.
> and that we should give the following.
> IOSTAT_EOR(-2), IOSTAT_EOR(-2), IOSTAT_END(-1)
I agree that this is sensible and what I expect (and what g95, ifort,
openf95, pathscale give). NAG gives EOR, EOF, EOF which I think is also
covered by the standard.
Using pad='no', ifort still gives EOR,EOR,END while NAG gives still
EOR,EOF,EOF. However, given the standard I prefer EOR,EOF,EOF as your
> Regression tested on x86-64.
> OK for trunk?
OK (independent whether it is required by the standard or "just" a
sensible choice for undefined behaviour.)
Thanks for your patch!
> I will add the testcase to the testsuite if this is
Can you check the iostat in the test case?
> Shall I capture this in a PR as well?
I think that's not needed as one can still go back to the mailing list
based on the check-in date. But if you think it makes it easier for the
future: Go ahead and fill a PR.