This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, libgfortran] PR29936 Missed constraint on RECL=specifier in unformatted sequential WRITE
- From: Jerry DeLisle <jvdelisle at verizon dot net>
- To: Thomas Koenig <Thomas dot Koenig at online dot de>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 22 Nov 2006 17:56:46 -0800
- Subject: Re: [Patch, libgfortran] PR29936 Missed constraint on RECL=specifier in unformatted sequential WRITE
- References: <4563FB7C.firstname.lastname@example.org> <20061122191128.GA6165@meiner.onlinehome.de>
Thomas Koenig wrote:
On Tue, Nov 21, 2006 at 11:25:48PM -0800, Jerry DeLisle wrote:
The attached patch adds a flag to the units flags structure to identify if
a RECL= was specified in the OPEN statement. This flag is then initialized
in new_unit and is used in us_write to not set the current_unit->recl to
This will compilcate my large-record patch somewhat. I am currently
using current_unit->recl to keep track of the subrecord length,
so I will need to introduce additonal bookkeeping (and separate
the codepaths for unformatted direct and unformatted sequential
on reading, which might not be a bad idea).
Can you use last_record of strm_pos to track subrecord length?
Or you can add a new variable there in gfc_unit fairly safely since the unit
structure is allocated at run time and should be fairly safe compatibility wise.
Re-setting the record length in us_write doesn't do anything useful
at the moment as far as I have been able to determine.
I don't understand this statement. The patch I applied is not resetting the
record length, it is allowing the RECL= passed in the OPEN to go unchanged. It
was being set to maxrec to allow the record length to default to the size of the
output list. If you mean that it does not have to be done in us_write and could
be done somewhere else, I agree that it could be.
Of course, if we can't use RECL= on in an OPEN statement to set
the maximum subrecord size, then we are in trouble as far as a
test case for subrecord sizes is concerned. We can hardly write
out a 2GB record each time in the testsuite, so we need some other
way to specify a shorter maximum record length in the testsuite.
We do not necessarily need a test case for a huge record in the test suite. I
had to remove a large file I/O test case I had because it caused some systems to
hang if they did not have enough free disk space to execute it. I think this is
another case like that where we test outside of the test suite and call it good.
I would rather not add another option, but I am not objecting.
Why not compute the subrecord size from the record size passed in RECL= ? Maybe
there is an optimal subrecord size for performance.
The only way would be a new option, such as -fsubrecord-maxlength=
which we could then use in the test suite (and which would be
largely useless for anything else).
I will commit to trunk as simple and obvious along with a suitable test
I'd rather if you didn't. I agree that this is a bug that should
be fixed (and you can assign the PR to me if you want to),
although I'd tend to issue a warning by default (be liberal
in what you accept, conservative in what you send :-)
Too late, I did it last night. :)