Re: Allocatable arrays in derived types

<paul.richard.thomas@xxxxxxxxx> wrote in message
news:cec5fd4c-249f-4863-8bfd-66b55852ea87@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

There is a mechanism in gfortran for handling pointers whose strides
are not in element storage units. Unfortunately, it is broken for the
extra level of indirection, as you point out. This is in our bug
database as PR34640 and has been waiting for me to find the time to
fix it. I have been casting around for a way to do it that does not
require modification of the ABI for passing every other type of array.
You might imagine that this would be a rather mammoth task:) I have a
scheme for doing it in mind that is awaiting testing.

Good luck on achieving success without modifying the ABI. I have
seen folks say that it's possible to implement assumed-shape dummies
via copy-in/copy-out techniques even though they have to behave as if
they were passed via a descriptor. However, AFAIK everyone who is
interested in conforming to the standard seems to pass a descriptor
when both actual argument and the assumed-shape dummy argument have
the TARGET attribute. Otherwise what do you do when a subsequent
procedure call results in a copy of pointers to the dummy argument
which gets encoded somehow, sent out the network, and after return
gets retrieved from the network, decoded and used to point at the
original array? Somehow you would have to be able to reconstruct
the addresses it originally pointed at, so it needs some extra
data that allows it to perform this feat. Seems like the simplest
path would be to just fix the descriptors, but maybe have have
something really clever and elegant up your sleeve...

Has gfortran implemented the bounds-remapping-list yet?

C:\gfortran\clf\remap>type remap.f90
program remap
implicit none
integer, target :: A(12)
integer, pointer :: p(:,:)
integer i

A = [(i,i=1,size(A))]
p(1:3,1:4) => A
write(*,'(3(i0:1x))') p(:,2)
end program remap

C:\gfortran\clf\remap>gfortran remap.f90 -oremap
remap.f90:8.4:

p(1:3,1:4) => A
1
Error: Different ranks in pointer assignment at (1)

Guess not. Is your workaround going to be robust in the face of this
potential complication?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.