http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Last reconfirmed| |2012-12-19
Resolution|FIXED |
Ever Confirmed|0 |1
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-19
18:20:10 UTC ---
First: I think one should add a pass to frontend-passes.c, similar to
doloop_code. The reason is that resolve comes too early for some checks.
Quoting from resolve.c:
/* If a PRIVATE variable is used in the specification expression of the
result variable, it might be accessed from outside the module and can
thus not be TREE_PUBLIC() = 0.
TODO: sym->attr.public_used only has to be set for the result variable's
type-parameter expression and not for dummies or automatic variables.
Additionally, it only has to be set if the function is either PUBLIC or
used in a generic interface or TBP; unfortunately,
proc_name->attr.public_used can get set at a later stage. */
Secondly, a reducted test case for the FoX issue of comment 7 is the following:
module m
private
public :: foo
interface foo
module procedure bar
end interface foo
contains
pure function mylen()
integer :: mylen
mylen = 42
end function mylen
subroutine bar(x)
character(len=mylen()) :: x
end subroutine bar
end module m
The following line in resolve.c's resolve_function should take care of setting
the public_use attribute, but it doesn't work:
3128 if (sym && specification_expr && sym->attr.function
3129 && gfc_current_ns->proc_name
3130 && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
3131 sym->attr.public_used = 1;
The reason is that
(gdb) p gfc_current_ns->proc_name->name
$6 = 0x7ffff6725fe0 "bar"
