[patch, PR 19303] Provide 4-and 8-byte record markers for fortran

Jerry DeLisle jvdelisle@verizon.net
Wed Mar 22 05:31:00 GMT 2006


:REVIEWMAIL:

Thomas Koenig wrote:
> Hello world,
> 
> here is a second attempt at implementing variable sized record markers.
> This patch does the right thing when -frecord-marker=8 is set on a
> system where off_t is 4 bytes (i.e. it extends the record marker).
> 
> Regression-tested on i686-pc-linux-gnu.  Documentation checked with "make dvi".
> OK for trunk?  Do we want this for 4.1?
> 
> 	Thomas
> 
> 2006-03-17  Thomas Koenig  <Thomas.Koenig@onlien.de>
> 
> 	PR fortran/19303
> 	* gfortran.h (gfc_option_t):  Add record_marker.
> 	* lang.opt:  Add -frecord-marker=4 and -frecord-marker=8.
> 	* trans-decl.c:  Add gfor_fndecl_set_record_marker.
> 	(gfc_build_builtin_function_decls): Set
> 	gfor_fndecl_set_record_marker.
> 	(gfc_generate_function_code):  If we are in the main program
> 	and -frecord-marker was provided, call set_record_marker.
> 	* options.c (gfc_handle_option):  Add handling for
> 	-frecord-marker=4 and -frecord-marker=8.
> 	* invoke.texi:  Document -frecord-marker.
> 
> 2006-03-17  Thomas Koenig  <Thomas.Koenig@onlien.de>
> 
> 	PR fortran/19303
> 	* libgfortran.h (compile_options_t):  Add record_marker.
> 	* runtime/compile_options.c (set_record_marker):
> 	New function.
> 	* io/open.c:  If we have four-byte record markers, use
> 	GFC_INTEGER_4_HUGE as default record length.
> 	* io/file_pos.c (unformatted_backspace):  Handle
> 	different size record markers.
> 	* io/transfer.c (us_read):  Likewise.
> 	(us_write):  Likewise.
> 	(next_record_r):  Likewise.
> 	(write_us_marker):  Likewise.
> 	(next_record_w):  Likewise.
> 
> 2006-03-17  Thomas Koenig  <Thomas.Koenig@online.de>
> 
> 	PR fortran/19303
> 	* gfortran.dg/record_marker_1.f90:  New test case.
> 	* gfortran.dg/record_marker_2.f:  New test case.
> 	* gfortran.dg/record_marker_3.f90:  New test case.
> 
> 
Thomas,

I reviewed this patch and tested with all my available IO exercising programs 
and all tests fine with -frecord-marker=4 (NIST, mega-IO, regression).  I sent 
some minor editorial/whitespace comments to you off list.

This is OK for Trunk.  I assume that you will work pr26735 as a separate patch.

As for 4.1, I think this would be good to have.  I think it could be considered 
a regression relative to g77, but it is really a new feature.  I would wait 
until the fix for 26735 is ready and give this patch a week or so on trunk to 
allow some exercise by others before applying to 4.1.

Anyone else please chime in if you will.

Best Regards,

Jerry





More information about the Gcc-patches mailing list