https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554
--- Comment #3 from Tamas Bela Feher <tamas.bela.feher at ipp dot mpg.de> --- Dear Dominique, Thank you for looking into the problem. > Why do you want to use such constructs? I was refactoring and splitting large modules into submodules when I accidentally run into this problems. I could get around by simply renaming the variables. I also agree with you, that using such constructs is asking for trouble. The main question is whether the standard forbids this construct or not. If it does not, then the compiler should not give any error message. A warning could be given if you really deem it dangerous. > How do you parse [...] ? If I understood correctly, section 16.3.1 establishes that variable i belongs to class (1) of local identifiers, and such identifiers shall not be the same as a global identifier. Further in section 16.3.1 we can find that "Within its scope, a local identifier of one class shall not be the same as another local identifier of the same class." None of these restrictions apply. The submodule (as a program unit) should be considered as a separate scoping unit: "1.3.124 scoping unit BLOCK construct, derived-type definition, interface body, program unit, subprogram, excluding all nested scoping units in it" "Note 2.4 A submodule has access to entities in its parent module or submodule by host association." I did not find any specific restrictions for host association in case of submodules, therefore I would use the general rule: "16.5.1.4 Host association [...] A name that appears in the scoping unit as [...] (2) an object-name in an entity-decl [...] is a local identifier in the scoping unit and any entity of the host that has this as its nongeneric name is inaccessible by that name by host association." Considering all the above, I would interpret the attached code (repeated here) the following way: 1 module M 2 implicit none 3 integer :: i = 0 4 interface 5 module subroutine write_i() 6 end subroutine 7 end interface 8 end module 9 10 submodule (M) S 11 integer :: i = 137 12 contains 13 module subroutine write_i() 14 write (*,*) i 15 end subroutine 16 end submodule Line 3 declares local variable i in the scoping unit of module M. Line 11 declares a local variable with the same name in the scoping unit of submodule S (which is separate from the scoping unit of M). The variable i in line 14 refers to the local variable from the scoping unit of S. The program is correct, the error message that GFortran gives is incorrect. I have also tried a recent version of IBM's XL-Fortran compiler (15.1.5) and it compiles the code without any error message.
