Am 12.07.2013 23:07, Thomas Koenig wrote:
here is a rather self-evident patch for PR 52669.
Regression-tested. OK for trunk?
I think you should also handle:
module m
private
integer :: k
end module m
and
module m2
integer :: ll
end module m2
when compiled with -fmodule-private.
I think that's not yet handled by your code. It is probably sufficient
to move the following code (in the same function) up before your check:
if (sym->attr.access == ACCESS_UNKNOWN
&& (sym->ns->default_access == ACCESS_PRIVATE
|| (sym->ns->default_access == ACCESS_UNKNOWN
&& gfc_option.flag_module_private)))
sym->attr.access = ACCESS_PRIVATE;
Otherwise, it looks okay to me.
Tobias
PS: We will have to change the check when submodules are supported. But
it is detectable in a module whether it is used as submodule; one can
even handle as additional special case that there is a submodule, but it
is in the same file.
2013-07-12 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/52669
* trans-decl.c (gfc_create_module_variable): Optionally
warn about private module variable which is not used.
2013-07-12 Thomas Koenig <tkoe...@gcc.gnu.org>
PR fortran/52669
* fortran.dg/module_variable_1.f90: New test.
