Strange behavior of a type-bound procedure

[kostas85]

Hello all,

In the following code a derived data type is defined holding by a integer allocatable array and two type-bound procedures. One initializes the array and the other adds an element(ind) to the array in a specific position. When the array is initialized by the new type-bound the test program gives the correct result, when initialized externally gives a wrong results. The code and results follow. Both cases compiler with previous version and 15.0.0 and give the same result. Please excuse me if this is a known issue, I am sorry I didn't have time to check the forums. Thanks. 

module lines

implicit none

type set
integer, dimension(:), allocatable :: ind
contains
procedure :: new_ind
procedure :: new_array
end type

contains

subroutine new_array(a_set,ind)
class(set), intent(inout) :: a_set
integer, dimension(:), intent(in) :: ind
!Make a copy of the indices array
if (allocated(a_set%ind)) deallocate(a_set%ind)
allocate(a_set%ind,source=ind)
end subroutine new_array


elemental subroutine new_ind(a_set,position,ind)
class(set), intent(inout) :: a_set
integer, intent(in) :: position, ind
integer, dimension(:), allocatable :: help
!Make a copy of the indices array
allocate(help,source=[a_set%ind(1:position-1),ind,a_set%ind(position:)])
call move_alloc(help,a_set%ind)
end subroutine new_ind

end module

program test

use lines

implicit none
type(set):: cl
integer, dimension(:), allocatable :: help

! uncommenting the line below gives a wrong result
allocate(cl%ind,source=[1:3])
! this gives a correct result
call cl%new_array([1:3])

print*, cl%ind
call cl%new_ind(position=2,ind=11)
print*, cl%ind
call cl%new_ind(position=2,ind=12)
print*, cl%ind

end program test

Wrong Result

           1           2           3
           1          11           2
           1          12          11

Correct Result

           1           2           3
           1          11           2           3
           1          12          11           2           3

[Kevin_D_Intel]

I reproduced the described behavior and reported this to Development (see internal tracking id below) for further analysis. I'll keep you posted.

(Internal tracking id: DPD200361771)

[Kevin_D_Intel]

From some additional investigation it was found the incorrect results occur at higher-levels of optimization. I don't know whether this is usable with your app from which the reproducer was derived, but the reproducer produces correct results when the caller of new_ind (the main program in this case) is compiled at -O0. Split the reproducer into two source files one containing module and the other the main, and then compile the main at -O0.

I will keep you updated as I learn more.
 

[Kevin_D_Intel]

Development has fixed this defect. I expect the fix in the IPS XE 2015 Update 2 (tentatively scheduled for February).