[J3] Changing address of an allocatable on assignment when shapes match

[Bill Long]

> On Aug 23, 2019, at 4:59 PM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> In https://stackoverflow.com/questions/57606191/memory-location-of-fortran-allocatable-arrays-on-assigment a user asks when the storage location of an allocatable array can change during intrinsic assignment. I responded that if the shapes (or lengths, or in the case of polymorphic, kinds) don't match, the variable is deallocated and then reallocated to match the expression. But if everything matches, is it conforming to do a reallocation anyway?
> 
> According to the user, Sun/Oracle Fortran Studio 12.6 (this may not be a current version) does the reallocate even if the shapes match (but doesn't in assignment to S(:). I could imagine that an implementor might do this to avoid copying data twice in case of an overlap, but it feels wrong to me. Other compilers I tried don't reallocate under these conditions. Also, the user reports that adding the TARGET attribute disables the reallocation.
> 
> What are people's thoughts on this - is it ok by the standard, even if a bit weird?



The standard’s wording is

"If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ.”


So, if the variable is allocatable, it is deallocated  IF  {any of a bunch of conditions occur}.  If none of the conditions occurs, then the standard (intentionally, I believe) does not mandate the deallocation.  It wold seem a poor implementation to unnecessarily deallocate and reallocate the variable in cases where it is not required.  None of the 4 implementations I have available appear to have done  the unnecessary deallocate and allocate. 


Output from compiler C:

> ./a.out
 1.,  4.,  9.,  16.,  25.,  36.,  49.
 6420608
 1.,  9.,  25.,  49.,  4.,  16.,  36.
 6420608
 1.,  25.,  4.,  36.,  9.,  49.,  16.
 6420608

Output from compiler I:

> ./a.out
   1.000000       4.000000       9.000000       16.00000       25.00000    
   36.00000       49.00000    
               7398080
   1.000000       9.000000       25.00000       49.00000       4.000000    
   16.00000       36.00000    
               7398080
   1.000000       25.00000       4.000000       36.00000       9.000000    
   49.00000       16.00000    
               7398080


Output from compiler P:

> ./a.out
    1.000000        4.000000        9.000000        16.00000     
    25.00000        36.00000        49.00000    
                  6316672
    1.000000        9.000000        25.00000        49.00000     
    4.000000        16.00000        36.00000    
                  6316672
    1.000000        25.00000        4.000000        36.00000     
    9.000000        49.00000        16.00000    
                  6316672


Output from compiler G:

> ./a.out
   1.00000000       4.00000000       9.00000000       16.0000000       25.0000000       36.0000000       49.0000000    
              6318160
   1.00000000       9.00000000       25.0000000       49.0000000       4.00000000       16.0000000       36.0000000    
              6318160
   1.00000000       25.0000000       4.00000000       36.0000000       9.00000000       49.0000000       16.0000000    
              6318160

Cheers,
Bill



> 
> Steve
> 
> program test
> implicit none
> real, dimension(:), allocatable :: S
> integer :: i, idx(7) = [1,3,5,7,2,4,6]
> 
> allocate(S(size(idx)))
> do i=1,size(S)
>   S(i) = i*i
> end do
> 
> write(6,*) S
> write(6,*) loc(S)
> 
> S = S(idx)
> 
> write(6,*) S
> write(6,*) loc(S)
> 
> S(:) = S(idx)
> 
> write(6,*) S
> write(6,*) loc(S)
> 
> deallocate(S)
> 
> end program
> 
> $ sunf90 -V
> f90: Studio 12.6 Fortran 95 8.8 Linux_i386 2017/05/30
> 
> $ sunf90 test.f90 ; ./a.out
>  1.0 4.0 9.0 16.0 25.0 36.0 49.0
>  37518752
>  1.0 9.0 25.0 49.0 4.0 16.0 36.0
>  37519840
>  1.0 25.0 4.0 36.0 9.0 49.0 16.0
>  37519840
> 

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425