http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #5 from janus at gcc dot gnu.org 2011-10-12 21:17:58 UTC ---
(In reply to comment #4)
> > This was rejected before, and still is with my patch.
>
> But should it be rejected? move_alloc does not modify the association status
> of
> "dt" - just of "dt%VALUE". Thus, I believe this test case is valid and, hence,
> gfortran should not reject it.
Huh, seems I misunderstood your comment.
I can't give any hard evidence right now, but naively I would say it should
indeed be rejected. Shouldn't the allocation status of the components be
protected by the "intent(in)"?
The following (equivalent) variant is at least rejected by gfortran 4.5 on
upwards:
TYPE MY_TYPE
INTEGER, ALLOCATABLE :: VALUE
END TYPE
CONTAINS
SUBROUTINE sub (dt)
type(MY_TYPE), intent(in) :: dt
deallocate(dt%VALUE)
END SUBROUTINE
end
deallocate(dt%VALUE)
1
Error: Dummy argument 'dt' with INTENT(IN) in variable definition context
(DEALLOCATE object) at (1)
