Severe problem with formatted write
Steve Kargl
sgk@troutmask.apl.washington.edu
Tue Aug 2 21:17:00 GMT 2005
On Tue, Aug 02, 2005 at 07:18:41PM +0200, Paul Thomas wrote:
>
> Index: gcc/libgfortran/io/transfer.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/libgfortran/io/transfer.c,v
> retrieving revision 1.50
> diff -c -3 -p -r1.50 transfer.c
> *** gcc/libgfortran/io/transfer.c 30 Jul 2005 05:33:33 -0000 1.50
> --- gcc/libgfortran/io/transfer.c 2 Aug 2005 17:08:18 -0000
> *************** data_transfer_init (int read_flag)
> *** 1171,1177 ****
> it is always safe to truncate the file on the first write */
> if (g.mode == WRITING
> && current_unit->flags.access == ACCESS_SEQUENTIAL
> ! && current_unit->current_record == 0)
> struncate(current_unit->s);
>
> current_unit->mode = g.mode;
> --- 1171,1177 ----
> it is always safe to truncate the file on the first write */
> if (g.mode == WRITING
> && current_unit->flags.access == ACCESS_SEQUENTIAL
> ! && current_unit->last_record == 0)
> struncate(current_unit->s);
>
> current_unit->mode = g.mode;
>
> Regtests on RH9 and all but three NIST tests run perfectly; fm908/9 fail
> for the lack of array internal units and test 9 in fm905 is failing.
> This is the best that gfortran has ever achieved with NIST. We are on
> to the last three!
>
I've regression tested the above patch on amd64-*-freebsd for
mainline. This patch causes no regression. Consider it
approved for committing once you write an appropriate ChangeLog.
--
Steve
More information about the Fortran
mailing list