> Remember that a reference to a pointer results in an automatic dereference of
its target. Thus, in
>
> pv = elemental_pointer_fun(6)
> arr(1) = pv
> deallocate (pv%vect) ! memory recovered
>
> one is deallocating the target of pv%vect, namely
"elemental_pointer_fun(6)%vect", (so to speak).

Okay. I understand. This means that using a defined assignment for the
pointer_vector type that does intrinsic assignment of pointer components instead
of pointer assignment is BAD in this case. After the function
elemental_pointer_fun has returned, "elemental_pointer_fun%vect" remains
allocated, and futhermore, there is nothing pointing to it, and hence no way of
deallocating it and recovering the memory.

All is not lost however, because I can still achieve what I wanted without using
defined assignment. In the main program I can have a separate pointer pointing
to the target vector. I can then do the intrinsic assignment of components and
deallocation afterwards. Using your example program...

program no_leaks

type p
integer, pointer, dimension(:) :: vect
end type p

type(p) pv1, pv2
integer, dimension(2), target :: target_vector

target_vector=0

! separate pointer pointing to target vector
pv1%vect => target_vector

pv2 = elemental_pointer_fun(5) ! memory leak
print *, pv2%vect

! intrinsic assignment
pv1%vect=pv2%vect

! recover memory
deallocate(pv2%vect)
nullify(pv1%vect)

print *,target_vector

contains

   TYPE(p) ELEMENTAL FUNCTION &
   & elemental_pointer_fun(index) RESULT(ans)

   IMPLICIT NONE

   INTEGER, INTENT(IN) :: index

   ALLOCATE(ans%vect(2))
   ans%vect=(/index,-index/)

   END FUNCTION elemental_pointer_fun

end program no_leaks

I have ammended my original program so that it has no memory leaks. On compaq it
now compiles with no warnings or errors... but gives the wrong results if a
WHERE is used . (A worse situation than before). The Sun compiler gives the
correct results. I have attached the no-leaks version in case anyone wants to
have a play.

Thanks to everyone for all their help!

Paul