[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/80708] New: [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708

Bug ID: 80708
   Summary: [f08] ALLOCATE with MOLD error if source-expr is a
derived type with null-init pointer component
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamas.bela.feher at ipp dot mpg.de
  Target Milestone: ---

Dear GFortran Team,

For the following program:

program mold_dtype_with_pointer_component
  implicit none
  type t
real, dimension(:), pointer :: p => null()
  end type
  type(t), dimension(3:4) :: array
  type(t), allocatable, dimension(:) :: h
  allocate(H, mold=array)
end program

GFortran (versions 6.3.0 and 8.0.0 20170427) gives the following error message:

gfortran mold_dtype_pointer.f90
mold_dtype_pointer.f90:8:11:

   allocate(H, mold=array)
   1
Error: Array specification or array-valued SOURCE= expression required in
ALLOCATE statement at (1)

The error disappears if the null-init for pointer p is removed, or if MOLD is
replaced with SOURCE. I would expect that the program compiles even in its
original form.

Best regards,
Tamas

[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] New: [f08] variable redefinition in submodule

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554

Bug ID: 80554
   Summary: [f08] variable redefinition in submodule
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamas.bela.feher at ipp dot mpg.de
  Target Milestone: ---

Created attachment 41281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41281&action=edit
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