Elemental subroutine causes pointer bad mapping when source allocation is used

[kostas85]

Hello again,

The following code is somewhat of an extension of my previous post. As before we define two derived type t1, t2 and three function. A function that produces as output an array of t2 and two function, an elemental and a classic one, whose output is a real. When source allocation is used to store the result of the elemental function producing the real, a pointer is erroneously mapped to the result. The mapping is correct when classic allocation is used. The code also behaves correctly independently of source/classic allocation when type t2 is defined by only one integer. The code follows along with correct/wrong results. This behavior is observed for both previous and current version. Please let me know if this is related to previous post regarding class/elemental subroutine. Since I was not sure I decided to create a different post. Thank you!

module type_funs

type t1
  integer :: i
end type t1

type t2
  integer :: i 
  ! commenting the integer below makes source 
  ! allocations to work properly
  integer :: j=0
end type t2

type(t1) :: t1_start = t1(0)

 contains

real elemental function uni_op(this) result(res)
type(t2), intent(in) :: this
res = this%i**2
end function uni_op

function uni_op_arr(this) result(res)
type(t2), intent(in),dimension(:) :: this
real, dimension(size(this)) :: res
res = this%i**2
end function uni_op_arr

function bin_op_arr(this,that) result(res)
type(t1), dimension(:), intent(in) :: this
type(t1), intent(in) :: that
type(t2), dimension(size(this)) :: res
res%i=this%i-that%i
end function bin_op_arr

end module type_funs


program test_funs

use type_funs

implicit none

! this produces wrong results
type(t1), dimension(:), allocatable :: t1arr
real,dimension(:), allocatable,target :: values
real,dimension(:), pointer :: pvalues

allocate(t1arr(10))
t1arr%i=[1:10]

! commenting source allocation and uncommenting the "classic" one
! gives always correct results for the elemental function gives the 
! correct result, the result is always correct when uni_op_arr is used
allocate(values, source=uni_op(bin_op_arr(t1arr,t1_start)))
!allocate(values, source=uni_op_arr(bin_op_arr(t1arr,t1_start)))
!allocate(values(10))
!values = uni_op(bin_op_arr(t1arr,t1_start))

print *, values
pvalues => values

print *, pvalues

end program test_funs

Wrong Result

  1.000000       4.000000       9.000000       16.00000       25.00000    
   36.00000       49.00000       64.00000       81.00000       100.0000    
   1.000000       9.000000       25.00000       49.00000       81.00000    
  0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00  0.0000000E+00

Correct Result

   1.000000       4.000000       9.000000       16.00000       25.00000    
   36.00000       49.00000       64.00000       81.00000       100.0000    
   1.000000       4.000000       9.000000       16.00000       25.00000    
   36.00000       49.00000       64.00000       81.00000       100.0000    

[Kevin_D_Intel]

For this case, I found the correct results are produced with the final 13.1 release, Version 13.1.3.192 Build 20130607, and the incorrect results occur with the initial 14.0 release, Version 14.0.0.080 Build 20130728.

I will investigate further and post another update shortly.

[kostas85]

I am not keeping track of versions older than the previous. So I am compiling with Version 14.0.3.174 Build 20140422 and the last. Thanks a lot for your interest.

[Kevin_D_Intel]

Thank you for the note about your ifort version. I confirmed the reproducer produces the unexpected mappings with both the 14.0 and 15.0 compilers and expected mappings for each work around you noted. I submitted this to Development (see internal tracking id below) as a separate defect from your earlier related post and will keep you updated on the status as I learn it.

(Internal tracking id: DPD200362026)

(Resolution Update on 11/26/2015): This defect is fixed in the Intel® Parallel Studio XE 2016 Update 1 Release (PSXE 2016.1.056 / CnL 2016.1.150 - Linux)

[Kevin_D_Intel]

I confirmed this issue is fixed in our upcoming Parallel Studio XE 2016 Update 1 release which should be available soon.