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 09:47:40PM +0100, Paul Thomas wrote:
> >
> >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.
> >
> >
> I'll take a look at your posts - I have more than once asked for m4 help 
> as well.  I had thought like Tobi that it would be possible to cast to a 
> void* and let the array descriptor do the business.  Is that too naive?  
> Actually, on thinking about it, I suppose that the middle end has to do 
> so much that one might as well go the whole hog and do it all with 
> tree-ssa/scalarizer wizardary.  Maybe this would be easier than curing 
> the problem with elemental subroutines!  I'll put my thinking hat on.

Don't let me distract you from elemental subroutines.  One optimization
that we get for free if we do the work in the middle-end is constant
folding.  I've seen a few uses of transfer with constant arguments,
which I think gfc_simplify_transfer() misses (I need to check this),
that the middle-end should be able to eliminate.

> >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 
> >
> >
> ifort thinks this one is:
> 
> program z
>  integer(2), allocatable :: m(:)
>  integer i, s(10)
>  s = (/ (i, i=1,10) /)
>  print*, transfer(s((/2,8,3,6/)),m,8)  ! Is this legal?
> end program z
> 
> [prt@localhost prs]# ./a.out
>      2      0      8      0      3      0      6      0
> 
> It's exactly what the standard says, isn't it?  The bit pattern defined 
> by the source, projected onto the sink with the type and kind parameters 
> of mold.

Maybe.  I need to re-read the section 14.  TRANSFER is referencing m,
which has never been allocated.  I believe that there are restrictions 
on how an unallocated variable can be used.


-- 
Steve