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: Thomas Koenig <Thomas dot Koenig at online dot de>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- 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 20:11:28 +0100
- Subject: Re: [Patch, libgfortran] PR29936 Missed constraint on RECL=specifier in unformatted sequential WRITE
- References: <4563FB7C.firstname.lastname@example.org>
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).
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.
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.
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 :-)
As far as status is concerned, I was just about to regtest the
lates version of my patch, then write up a changelog entry.
Fixing this bug alongside will delay things somewhat.