Runtime crash with polymorphic types

[MR]

The attached code crashes when compiled with ifort 15.0 . The intended output should be (from a gfortran run)

$ ./test
 T
           1
 T
           1           2

module m1

 implicit none
 
 type, abstract :: c_abs
 end type c_abs

 type, extends(c_abs) :: t_cnt
  class(c_abs), allocatable :: f
 end type t_cnt

end module m1

!------------------------

module m2

 use m1, only: c_abs, t_cnt

 implicit none

 type, extends(c_abs) :: t_a
  integer, allocatable :: i(:)
 end type t_a

 type, extends(c_abs) :: t_b
  integer :: ndata
  type(t_cnt), allocatable :: data(:)
 end type t_b

contains

 pure function get_data(var) result(dat)
  class(t_b), intent(in) :: var
  type(t_cnt) :: dat(var%ndata)

   dat = var%data
 end function get_data
 
end module m2

!------------------------

program p
 use m1
 use m2
 implicit none

  type(t_b) :: b
  type(t_cnt), allocatable :: cnt(:)

  b%ndata = 1
  allocate( b%data( b%ndata ) )
  allocate( t_a :: b%data(1)%f )
  select type( a => b%data(1)%f )
   type is(t_a)
    allocate( a%i(2) )
    a%i = (/ 1 , 2 /)
  end select


  cnt = get_data( b )
  write(*,*) allocated(cnt)
  write(*,*) size(cnt)
  write(*,*) allocated( cnt(1)%f )
  select type( a => cnt(1)%f )
   type is(t_a)
    write(*,*) a%i
  end select

end program p

[Kevin_D_Intel]

Thank you for the report. I will investigate and post again soon.

[Kevin_D_Intel]

The crash is reproducible with our 15.x and 14.x compilers; however, the program runs successfully with the upcoming 16.0 compiler in the Parallel Studio XE 2016 release. The program also crashes using the initial 16.0 Beta and runs successfully using the 16.0 Beta Update 1 compiler. As a final test, I used the latest 16.0 development compiler and find the program also runs successfully.

While it appears a fix in the Beta update 1 has led to the correct program behavior, I have been unable to identify any previously reported defect that I could definitely say represented the issue has been fixed.

At this time it appears the issue is fixed in the upcoming 16.0 compiler and we can revisit the investigation if it resurfaces in a future compiler. I’m sorry I could not provide a more definitive resolution for you than this.

[MR]

OK, thank you.

Marco