https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554
--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> --- (In reply to Tamas Bela Feher from comment #0) > Created attachment 41281 [details] > submodule redefines a variable from the ancestor module > > Dear GFortran team, > > In the attached program, module M and its submodule S both define a > variable with the name i. This triggers an error message in GFortran 6.3.0 > and also in the latest version form SVN trunk. > > The Intel Fortran compiler accepts the code, and the compiled code produces > the following output: > ./a.out > 137 > > I think GFortran should also accept the code. As far as I know, entities > from the ancestor module are host associated, and we should be allowed to > specify a local entity in the submodule with the same name. Or is there any > restriction in the standard which forbids it? > > Could you look into this problem? Thank you for your help. > > Best regards, > Tamas > > > $ cat submod_var_scope.f90 > module M > implicit none > integer :: i = 0 > interface > module subroutine write_i() > end subroutine > end interface > end module > > submodule (M) S > integer :: i = 137 > contains > module subroutine write_i() > write (*,*) i > end subroutine > end submodule > > program test_submod_variable > use M > implicit none > i = 42 > call write_i > end program > > $ gfortran-6 -v submod_var_scope.f90 > Driving: gfortran-6 -v submod_var_scope.f90 -l gfortran -l m -shared-libgcc > Using built-in specs. > COLLECT_GCC=gfortran-6 > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto- > wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../gcc-6.3.0/configure --program-suffix=-6 > Thread model: posix > gcc version 6.3.0 (GCC) > COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' > /usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/f951 submod_var_scope.f90 > -quiet -dumpbase submod_var_scope.f90 -mtune=generic -march=x86-64 -auxbase > submod_var_scope -version -fintrinsic-modules-path > /usr/local/lib/gcc/x86_64-pc-linux-gnu/6.3.0/finclude -o /tmp/ccq0YC9g.s > GNU Fortran (GCC) version 6.3.0 (x86_64-pc-linux-gnu) > compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version > 3.1.3, MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > GNU Fortran2008 (GCC) version 6.3.0 (x86_64-pc-linux-gnu) > compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version > 3.1.3, MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > submod_var_scope.f90:11:14: > > integer :: i = 137 > 1 > Error: Symbol ‘i’ at (1) already has basic type of INTEGER > > > $ gfortran-svn -v submod_var_scope.f90 > Driving: gfortran-svn -v submod_var_scope.f90 -l gfortran -l m -shared-libgcc > Using built-in specs. > COLLECT_GCC=gfortran-svn > COLLECT_LTO_WRAPPER=/opt/gcc-svn/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto- > wrapper > Target: x86_64-pc-linux-gnu > Configured with: ../gcc-svn-trunk/configure --prefix=/opt/gcc-svn > --program-suffix=-svn --enable-languages=c,fortran > Thread model: posix > gcc version 8.0.0 20170427 (experimental) (GCC) > COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' > /opt/gcc-svn/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/f951 > submod_var_scope.f90 -quiet -dumpbase submod_var_scope.f90 -mtune=generic > -march=x86-64 -auxbase submod_var_scope -version -fintrinsic-modules-path > /opt/gcc-svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/finclude -o /tmp/ccRu9s2z.s > GNU Fortran (GCC) version 8.0.0 20170427 (experimental) (x86_64-pc-linux-gnu) > compiled by GNU C version 8.0.0 20170427 (experimental), GMP version > 6.1.2, MPFR version 3.1.3, MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 > GNU Fortran2008 (GCC) version 8.0.0 20170427 (experimental) > (x86_64-pc-linux-gnu) > compiled by GNU C version 8.0.0 20170427 (experimental), GMP version > 6.1.2, MPFR version 3.1.3, MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 > submod_var_scope.f90:11:14: > > integer :: i = 137 > 1 > Error: Symbol ‘i’ at (1) already has basic type of INTEGER As you correctly point out, entities from the parent module are host associated in the submodule. Thus, the message is absolutely correct and the nub is whether or not this is an error. Somewhere in the deep and distant past a bug report came up concerning double declarations of TKR within a scoping unit. The gfortran developers at the time determined that this was not allowed or, rather, should not be allowed. This is the reason why gfortran is flagging up an error. I cannot find anything in the standard that overrides the normal interpretation of host association in submodules and so I think that you are correct to say that this is a bug. I will take it. Thanks Paul
