This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Problem with LOC intrinsic for assumed size arrays
Steve,
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.
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
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.
Paul