Re: Problem with LOC intrinsic for assumed size arrays

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Wed, Jan 25, 2006 at 07:38:46PM +0100, Tobias Schl?ter wrote:
> Steve Kargl wrote:
> > On Wed, Jan 25, 2006 at 05:25:48PM +0100, Paul Thomas wrote:
> >>... which is why I think that a library function would do fine. I think 
> >>that the overhead of a function call is worth having over an incomplete 
> >>transfer intrinsic.
> > 
> > It isn't a single library function.  You need library functions
> > for all possible combinations of types and kind type parameters
> > for both SOURCE and MOLD (with and without SIZE).  In one of
> > my posts from several months ago, I estimated that we needed 
> > something like 168 functions.  Sure, some or all of these
> > functions could be autogenerated, but my request for help with
> > m4 went unanswered.
> > 
> > GFC_REAL4 *
> > gfc_transfer_r4_r4(GFC_REAL4 *source, GFC_REAL4 *mold, GFC_INTEGER4 *size)
> > {
> >    if (size) {
> >       src = somepackingfunc(source)
> >       len = somefuncof(size, sizeof(mold))
> >       return ((GFC_REAL4*) memcpy(dst,src,len));
> >    } else {
> >      yada
> >    }
> > }
> 
> I've not thought through TRANSFER well, but couldn't we use void * together
> with a size?  We don't need any type information beyond the size, right?
> 

>From the standard.

Result Characteristics.

  The result is of the same type and type parameters as MOLD.
  Case (i):   If MOLD is a scalar and SIZE is absent, the result is a
              scalar.  (gfortran has this implemented in trans-intrinsic.c).

  Case (ii):  If MOLD is an array and SIZE is absent, the result is an
              array and of rank one.  Its size is as small as possible such
              that its physical representation is not shorter than that of
              SOURCE.

  Case (iii): If SIZE is present, the result is an array of rank one and
              size SIZE.

So, MOLD provides the type and type parameters.  MOLD's effect on the
length of the return entity depends on whether SIZE is present.  Because
SOURCE can be an array section, I think we need to pack SOURCE into
a contigous chunk of memory and use memcpy() where we need to be careful
with buffer over/under runs.  Consider, 

   integer :: i = 100
   character :: a = 'a'
   real x, y(i)
   x = 1.
   y = transfer(a,x,i)
   end

The leading byte comes from 'a', and remaining bytes are processor 
dependent.  gfortran should probably ensure that the naive memcpy()
doesn't write 399 bytes from memory following the 'a' into y.
 
-- 
Steve