Re: Update: [patch, libfortran] Fix EOF handling in array I/O

[Jerry DeLisle <jvdelisle at charter dot net>]

On 11/24/19 2:25 AM, Thomas Koenig wrote:
> Here's an update to the previous patch.
>
> Upon reflection, I think it is better for performance to have two
> versions of the loop so the test is only performed when it is
> needed.
>
> So, OK for trunk?
>
> Regards
>
>      Thomas

Hi Thomas et al,

The patch is OK to commit, but I want to call attention to something we do in 
the front-end.  From -fdump-tree-original of your test case you can see that we 
call different transfer functions for READ vs WRITE operations.  This 'feature' 
is provided for all the transfers and we split READ and WRITE so that one would 
not have to do a condition check at runtime.

Thusly:

      _gfortran_st_write (&dt_parm.2);
      {
        struct array02_real(kind=8) parm.3;

        parm.3.span = 8;
        parm.3.dtype = {.elem_len=8, .rank=2, .type=3};
        parm.3.dim[0].lbound = 1;
        parm.3.dim[0].ubound = 10;
        parm.3.dim[0].stride = 1;
        parm.3.dim[1].lbound = 1;
        parm.3.dim[1].ubound = 3;
        parm.3.dim[1].stride = 10;
        parm.3.data = (void *) &res[0];
        parm.3.offset = -11;
        _gfortran_transfer_array_write (&dt_parm.2, &parm.3, 8, 0);
      }
      _gfortran_st_write_done (&dt_parm.2);

One can see that transfer_array_write is invoked and in libgfortran it simply 
calls transfer_array. I thought at one time we were actually using the feature 
and I started looking for it today when I noticed you want to split the READ vs 
WRITE in the transfer inner.

In short, one could choose to factor these into the two functions already 
defined and get rid of the conditional since it is done at compile time.

Now it may make sense for the inner array to do this and later we can consider 
whether any of the other transfers warrant refactoring. (For a future patch)

Regards,

Jerry