This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with LOC intrinsic for assumed size arrays


Paul Thomas wrote:
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).

I figured you knew that, but it seemed worth confirming along with what you appeared to be questioning. :)


As to allocation status:
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.

My interpretation is that this is indeed behavior required by the standard. The array m() has a well-defined type and kind parameter regardless of whether it is allocated or not, and this is all that is referenced in this case.


The transfer(s((/2,8,3,6)),m) case may be a bit more interesting, however. For determining whether the result is a scalar or an array, the standard refers not to whether MOLD is declared as a scalar or an array, but to whether it is "scalar or array valued". As unallocated arrays are undefined and by 2.5.4 they do not have a valid value, it seems to me that they are not, strictly speaking, "array valued".

Thus, I would conclude that in the latter case the behavior of the transfer intrinsic is undefined by the standard -- but that the compiler is not required to throw an error, and it would be a completely acceptable extension for it to give the same answer as if m() were allocated.

A similar pedantic uncertainty arises if m() is allocated but not defined, or for that matter if it is an undefined scalar, when SIZE is not given.

- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]