[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #6 from Paul Thomas --- Added by hand because I used the wrong file for the -F option on commit to 7-branch: Author: pault Date: Wed Nov 1 11:29:07 2017 New Revision: 254299 URL: https://gcc.gnu.org/viewcvs?rev=254299&root=gcc&view=rev Log: 2017-11-01 Paul Thomas 2017-11-01 Paul Thomas PR fortran/80554 * decl.c (build_sym): In a submodule allow overriding of host associated symbols from the ancestor module with a new declaration. 2017-11-01 Paul Thomas PR fortran/80554 * gfortran.dg/submodule_29.f08: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_29.f08 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #7 from Paul Thomas --- Author: pault Date: Wed Nov 1 12:39:48 2017 New Revision: 254303 URL: https://gcc.gnu.org/viewcvs?rev=254303&root=gcc&view=rev Log: 2017-11-01 Paul Thomas PR fortran/80554 * decl.c (build_sym): In a submodule allow overriding of host associated symbols from the ancestor module with a new declaration. 2017-11-01 Paul Thomas PR fortran/80554 * gfortran.dg/submodule_29.f08: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_29.f08 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/decl.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Paul Thomas --- Fixed on 6-, 7- and 8-branches. Thanks for the report. Paul
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #9 from Tamas Bela Feher --- Thank you for fixing the problem!
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-05-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > 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? How do you parse > 16.3 Local identifiers > 16.3.1 Classes of local identifiers > 1 Identifiers of entities in the classes > (1) except for statement or construct entities (16.4), named variables, > named constants, named constructs, statement functions, internal > procedures, module procedures, dummy procedures, intrinsic procedures, > external procedures that have binding labels, intrinsic modules, > abstract interfaces, generic interfaces, derived types, namelist groups, > external procedures accessed via USE, and statement labels, > (2) type parameters, components, and type-bound procedure bindings, > in a separate class for each type, > (3) argument keywords, in a separate class for each procedure with an > explicit interface, and > (4) common blocks that have binding labels > are local identifiers. > 2 Within its scope, a local identifier of an entity of class (1) or class (4) > shall not be the same as a global identifier used in that scope unless > the global identifier > • is used only as the use-name of a rename in a USE statement, > • is a common block name (16.3.2), > • is an external procedure name that is also a generic name, or > • is an external function name and the inclusive scope is its defining > subprogram (16.3.3). ? Why do you want to use such constructs? IMO, if they are not forbidden, using them is asking for trouble.
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 Dominique d'Humieres changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- Note that if I replace the two lines integer :: i = ... with integer :: i I get the same error.
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #3 from Tamas Bela Feher --- 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() 14write (*,*) 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.
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #4 from Paul Thomas --- (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
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 Paul Thomas changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug fortran/80554] [f08] variable redefinition in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue May 16 20:09:02 2017 New Revision: 248129 URL: https://gcc.gnu.org/viewcvs?rev=248129&root=gcc&view=rev Log: 2017-05-16 Paul Thomas PR fortran/80554 * decl.c (build_sym): In a submodule allow overriding of host associated symbols from the ancestor module with a new declaration. 2017-05-16 Paul Thomas PR fortran/80554 * gfortran.dg/submodule_29.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/submodule_29.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog