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

Malcolm Cohen malcolm at nag-j.co.jp
Fri Aug 23 20:17:34 EDT 2019

I should add that this (no reallocation unless something changed) was a deliberate design decision, as doing the reallocation unnecessarily would have been an incompatible change from Fortran 90/95, which did not permit the reallocation at all.

As in, the Sun compiler behaviour, assuming it does that when the TARGET attribute is present, would break some standard-conforming Fortran 90/95 programs.


From: Malcolm Cohen via J3 
Sent: Saturday, August 24, 2019 9:10 AM
To: General J3 interest list 
Cc: Malcolm Cohen 
Subject: Re: [J3] Changing address of an allocatable on assignment when shapes match

It is conforming to do the reallocation in the sample program. Actually, the sample program is not conforming, as it uses a nonstandard intrinsic, so technically it’s okay to do anything.

In general, it would not be conforming to do the reallocation if the allocatable array has the TARGET attribute, as this would break the Fortran pointer association semantics.

If LOC( X ) is merely shorthand for TRANSFER(C_LOC( X ),0), the TARGET attribute is necessary anyway to make the program conforming.


From: Steve Lionel via J3 
Sent: Saturday, August 24, 2019 6:59 AM
To: fortran standards email list for J3 
Cc: Steve Lionel 
Subject: [J3] Changing address of an allocatable on assignment when shapes match

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?


program test
implicit none
real, dimension(:), allocatable :: S
integer :: i, idx(7) = [1,3,5,7,2,4,6]

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)


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
1.0 9.0 25.0 49.0 4.0 16.0 36.0
1.0 25.0 4.0 36.0 9.0 49.0 16.0


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20190824/de2071be/attachment-0001.html>

More information about the J3 mailing list