2
votes

I have a small code declaring a pointer to array of derived type which has a field that is an allocatable array of another derived type having a real variable as a field. Using gnu fortran (8.2) I obtain different results for each location in the array or as a vector.

Using intel fortran (2019.4) compiler succeeded.

program test
implicit none
integer, parameter :: length = 2
real(8), dimension(length) :: a, b
integer :: i

type point
   real(8) :: x
end type point

type stored
   type(point), dimension(:), allocatable :: np
end type stored

type(stored), dimension(:), pointer :: std=>null()


allocate(std(1))
allocate(std(1)%np(length))
std(1)%np(1)%x = 0.3d0
std(1)%np(2)%x = 0.3555d0

do i = 1, length
   write(*, "('std(1)%np(',i1,')%x = ',1e22.14)") i, std(1)%np(i)%x
end do
do i = 1, length
   write(*, "('std(1)%np(1:',i1,') = ',2e22.14)") i, std(1)%np(1:i)%x
end do
a = std(1)%np(1:2)%x
b = [std(1)%np(1)%x, std(1)%np(2)%x]
if (norm2(a - b) .gt. 1d-3) then
   write(*,*) 'failure'
else
   write(*, *) 'success'
end if
end program test

the code terminates successfully, but using gfortran one obtains 'failure' on screen and inconsistent prints above and using Intel compiler one obtains 'success' on screen and consistent prints above.

2
Attaching the option "-fsanitize=address -g" for gfortran may be useful because it gives a runtime error with the source line (where a memory issue occurs, pointing to the line std(1)%np(1:2)%x). On my machine, using gfortran-4.9 or 5 (or using allocatable instead of pointer for "std") removes the error. - roygvib

2 Answers

2
votes

It's not clear to me what your question is, unless it's the title. If so, no, pointers to derived types are fine. Your program correctly allocates std as an extent-1 array and then allocates std(1)%np(2). It then assigns to the x subcomponents of both np elements. Looks fine to me.

There are several things that could potentially cause "failure" - you should run the gfortran code in the debugger to see what is going wrong.

0
votes

The problem presented in the code above was resolved in the following [link] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077