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 05:25:48PM +0100, Paul Thomas wrote:
> Steve,
> 
> >I've thought about this one for awhile.  I think that a
> >library function is not what we want.  Unfortunately, I haven't
> >had the time to learn enough about trans-*.c functions and
> >tree SSA to fix it.  Basically, TRANSFER is a glorified
> >memcpy.
> > 
> >
> ... 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
   }
}

> >If we have TRANSFER(SRC,MOLD,SIZE) where SRC is an array
> >section, I think we need to create a temporary of the 
> >packed array section.  If MOLD is an array section, I have
> >no idea what that means, and I haven't had the time to 
> >write a bunch of test code.  My interpretation of standard
> >is that only the type and kind type parameters of MOLD are
> >important, its arrayness has no affect in writing portions
> >of SRC to the target variable.
> > 
> The standard specifies that it is the bit pattern of source, whatever 
> that may be, is written to something with the type and kind parameters 
> of mold and a scalar, if mold is scalar, otherwise a vector.

To you and Brooks, yes, I knew that MOLD determined whether the
return value was scalar or a rank 1 array.  With respect to MOLD's
other array properties (ie, assumed-size, assume-shape, etc), no
other property is important.  Indeed, the allocation status of an
allocatable MOLD may be unimportant (I haven't investigated this).

program z
  real, allocatable :: m(:)
  integer i, s(10)
  s = (/ (i,1=1,10) /)
  print*, transfer(s(1:10:2),m,3)  ! Is this legal?
end program z 

-- 
Steve