http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #16 from janus at gcc dot gnu.org 2013-02-06 10:54:39 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > + if (fsym && fsym->attr.optional && sym && sym->attr.pointer)
>
> Shouldn't you use something like
> gfc_expr_attr(expr).pointer
> Otherwise, I fear it will fail for var%comp
Agreed.
> Additionally, one might have to handle
> - unallocated allocatables
> - NULL() [= EXPR_NULL]
> - CLASS(), (pointer|allocatable)?
Huh, good point. Here is an extended test case which tests some of these:
program main
implicit none
integer, pointer :: p(:)
integer, allocatable :: a(:)
type t
integer, pointer :: p(:)
integer, allocatable :: a(:)
end type
type(t) :: d
! (1) pointer
p => null()
call sub(p)
! (2) allocatable
call sub(a)
! (3) pointer component
d%p => null ()
call sub(d%p)
! (4) NULL
call sub(null())
contains
subroutine sub(x)
integer, intent(in), optional :: x(4)
end subroutine
end
In fact the NULL case is rejected with (certainly a bug):
call sub(null())
1
Warning: Actual argument contains too few elements for dummy argument 'x' (1/4)
at (1)
For the allocatable case, no packing is done at all (I guess it's just not
needed there, since an allocatable array, contrary to a pointer, is always
contiguous, right?).
The pointer component case looks completely analogous to the simple pointer
case in the dump, but for some reason I do not see the valgrind errors there.
