Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29273 Discussions

Different behavior Passing Real/Complex Arguments

dannycat
New Contributor I
829 Views
I am currently trying to convert a legacy FORTRAN IV program from essentially single precision to double by making as few modifications as possible. The program uses subroutine arguments to allow psuedo dynamic array sizes where some of these arrays are complex data types.

The original programpasses anreal*4 array into the subroutineand an effectively maps this onto a Complex*4 array withinand upon examining the data in the debugger this seems to work. However when both arrays are changed to Real*8 and Complex*8 this no longer seems to be the case. I have reproduced the problem in the program below.

program testcomp

implicit none

real*4 Q(2,10)
real*8 Q8(2,10)
integer j

call Sub4(Q)

write(*,'(A)') ' Real*4 Results'
do j = 1 , 10
write(*,'(2ES15.5)') Q(1,j),Q(2,j)
enddo

call Sub8(Q8)

write(*,'(/A)') ' Real*8 Results'
do j = 1 , 10
write(*,'(2ES15.5)') Q8(1,j),Q8(2,j)
enddo

read(*,*)

end

subroutine Sub4(T)

implicit none
complex T(10)
real r,im
integer i

do i = 1 , 10
r = float(i)
im = r/2.0
T(i) = cmplx(r,im)
enddo

return
end subroutine

subroutine Sub8(T)

implicit none
complex*8 T(10)
real*8 r,im
integer i

do i = 1 , 10
r = dble(float(i))
im = r/2.0d0
T(i) = dcmplx(r,im)
enddo

return
end subroutine

Real*4 Results
1.00000E+00 5.00000E-01
2.00000E+00 1.00000E+00
3.00000E+00 1.50000E+00
4.00000E+00 2.00000E+00
5.00000E+00 2.50000E+00
6.00000E+00 3.00000E+00
7.00000E+00 3.50000E+00
8.00000E+00 4.00000E+00
9.00000E+00 4.50000E+00
1.00000E+01 5.00000E+00

Real*8 Results
3.05176E-05 7.81250E-03
1.25000E-01 2.00000E+00
8.00000E+00 3.20000E+01
1.28000E+02 5.12000E+02
1.02400E+03 2.04800E+03
0.00000E+00 0.00000E+00
0.00000E+00 0.00000E+00
0.00000E+00 0.00000E+00
0.00000E+00 0.00000E+00
0.00000E+00 0.00000E+00


If you examine the contents of Q and Q8 they differ. ie Q looks OK but Q8 doesn't. I know this is not an ideal way of programming but I don't want to have to rewrite the whole program if it can be avoided. Is this as expected behavior and if it is does anyone know the best way to get this working correctly without resorting to a major rewrite?

This was compiled using CVF 6.6c (with Argument Mismatch check disabled)
0 Kudos
3 Replies
Steven_L_Intel1
Employee
829 Views

complex*8 is not the same as complex(8) complex*8 is single precision complex. You want complex*16 or complex(8).
0 Kudos
dannycat
New Contributor I
829 Views

complex*8 is not the same as complex(8) complex*8 is single precision complex. You want complex*16 or complex(8).

Steve,

Ah, I see, its obvious now. The 8 refers to both real & imaginary parts together. I've not used these data type before.

Thanks
0 Kudos
Steven_L_Intel1
Employee
829 Views
Put another way, the *n refers to the length of a value in bytes. A complex*8 is two real*4s.
0 Kudos
Reply