------- Comment #2 from burnus at gcc dot gnu dot org 2010-06-01 12:44 -------
Some debugging shows that at least for
gfc_match_call
the correct symtree is picked up via gfc_get_ha_sym_tree and saved into
new_st.symtree (tested via: attr.use_assoc == 1 and formal->sym->name == pvec).
However, the search is thrown over in resolve_call:
if (csym && gfc_current_ns->parent && csym->ns != gfc_current_ns)
gfc_find_sym_tree (csym->name, gfc_current_ns, 1, &st);
And this finds the wrong sym.
... Actually, that's incomplete - already c->symtree->n.sym has the wrong
symbol?!?
In case of functions/variables, it seems to go through check_host_association
- which somehow avoids this problem (cf. below).
* * *
As the following test case shows, only use-associated SUBROUTINES are
mishandled, use-associated module variables and use-associated FUNCTIONS are
handled correctly:
! { dg-do run }
!
! PR fortran/44360
!
module m
integer :: var = 43
contains
integer function fun()
fun = 42
end function fun
subroutine fun2()
print *, 'OK'
end subroutine fun2
end module m
module m2
integer :: var = -2 ! OK, never accessed
contains
subroutine test()
use m
call fun2() ! Calls ABORT()
if (fun() /= 42) call abort() ! OK
if (var /= 43) call abort() ! OK
end subroutine test
integer function fun()
call abort() ! OK, never called
fun = -3
end function fun
subroutine fun2()
call abort() ! <<< Should not be called but is
end subroutine fun2
end module m2
use m2
call test()
end
! { dg-final { cleanup-modules "m m2" } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44360
