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