This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, libgfortran] PR29936 Missed constraint on RECL=specifier in unformatted sequential WRITE


Thomas Koenig wrote:
On Tue, Nov 21, 2006 at 11:25:48PM -0800, Jerry DeLisle wrote:

Hi Jerry,

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 max_record.
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 case.

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. :)


Jerry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]