[Bug fortran/80554] [f08] variable redefinition in submodule

[tamas.bela.feher at ipp dot mpg.de]

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

[pault at gcc dot gnu.org]

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

[pault at gcc dot gnu.org]

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=gcc=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

[pault at gcc dot gnu.org]

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=gcc=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

[pault at gcc dot gnu.org]

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=gcc=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

[Bug fortran/80554] [f08] variable redefinition in submodule

[pault at gcc dot gnu.org]

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

[pault at gcc dot gnu.org]

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

[tamas.bela.feher at ipp dot mpg.de]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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.