This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/79107] New: ICE on name resolution within internal subroutine
- From: "baradi09 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 16 Jan 2017 19:08:27 +0000
- Subject: [Bug fortran/79107] New: ICE on name resolution within internal subroutine
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79107
Bug ID: 79107
Summary: ICE on name resolution within internal subroutine
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: baradi09 at gmail dot com
Target Milestone: ---
I get an ICE on the minimal self containing input below. Shifting the module
import from within the internal subroutine to the host (program) level avoids
the ICE. Also, enabling the type(Extended) to be public in module mod_test (by
commenting out the private statement in mod_test) avoids the ICE as well.
module mod_base
type :: Base
contains
procedure :: init
end type Base
contains
subroutine init(this)
class(Base), intent(inout) :: this
continue
end subroutine init
end module mod_base
module mod_extended
use mod_base
type, extends(Base) :: Extended
end type Extended
end module mod_extended
module mod_test
use mod_extended
! If you comment out the next line, no
private
public :: test
contains
subroutine test(this)
class(Extended), intent(inout) :: this
continue
end subroutine test
end module mod_test
program prg_test
use mod_extended
call run_test()
contains
subroutine run_test()
! If you import mod_test on the program level, no ICE
use mod_test
type(Extended) :: myExt
!!!
!!! ICE at next line
!!!
call myExt%init()
call test(myExt)
end subroutine run_test
end program prg_test