------- Comment #7 from pault at gcc dot gnu dot org 2006-08-17 14:57 -------
(In reply to comment #6)
OK I understand it now. The PRIVATE declaration prevents references to 'a' and
'b' from being resolved, when USEing dummybdy_comm, because it suppresses the
symtree. This is demonstrated by making 'a' and 'b' public in module
dummybdy_comm, or by inverting the order of the USE statements in 'sub' (yes,
they get USEd in inverted order!).
Your proposed patch is OK but the subsequent check on e->symtree is now
redundant and should be removed. I am just now regtesting the result and will
submit mit it and the testcase below tonight.
Thanks for the report.
Paul
! { dg-do compile }
! This tests the fix for PR28735 in which an ICE would be triggered in
resolve_ref
! because the references to 'a' and 'b' in the dummy arguments of mysub have
! no symtrees in module bar, being private there.
!
! Contributed by Andrew Sampson <[EMAIL PROTECTED]>
!
!-- foo.F -----------------------------------------------
module foo
implicit none
public
integer, allocatable :: a(:), b(:)
end module foo
!-- bar.F ---------------------------------------------
module bar
use foo
implicit none
private ! This triggered the ICE
public :: mysub ! since a and b are not public
contains
subroutine mysub(n, parray1)
integer, intent(in) :: n
real, dimension(a(n):b(n)) :: parray1
if ((n == 1) .and. size(parray1, 1) /= 10) call abort ()
if ((n == 2) .and. size(parray1, 1) /= 42) call abort ()
end subroutine mysub
end module bar
!-- sub.F -------------------------------------------------------
subroutine sub()
use foo
use bar
real :: z(100)
allocate (a(2), b(2))
a = (/1, 6/)
b = (/10, 47/)
call mysub (1, z)
call mysub (2, z)
return
end
!-- MAIN ------------------------------------------------------
use bar
call sub ()
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28735
