Possible bug

The following code compiles and runs in FTN95 Ver 8.70. An alternative compiler rejects this code (correctly?) since i is not defined as an integer.

program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
real(kind=dp) :: x(1:n) = (/(i,i=1,n)/), y(1:n) = (/(i,i=1,n)/)   !FTN compiler does not identify that i has no declared type
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main

This variation to the code runs with both compilers:

program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
integer a
real(kind=dp) :: x(1:n) = (/(a,a=1,n)/), y(1:n) = (/(a,a=1,n)/) 
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main

Removing the declaration of a as an integer, as in:

program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
real(kind=dp) :: x(1:n) = (/(a,a=1,n)/), y(1:n) = (/(a,a=1,n)/) 
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main

produces with FTN95

C:\Users\kenneth smith\Desktop\pl_pic_2\FreeFormat2.F95(4) : error 637 - Internal compiler error - floating point exception

Something strange is happening here.

Thanks Ken. I have made a note of this.

Paul,

Looking at this again, it appears as if the implied do loop in the array construct is “blind” to the IMPLICIT NONE statement and applies the default IMPLICIT REAL(A-H), INTEGER(I-N), REAL(O-Z), which could possibly explain the difference between the 1st and 3rd examples.

Ken

The scope of the DO index in an implied DO loop ought to be limited to the current statement. This was the motivation for a recent fix to FTN95. I will need to check when this fix took place.

My understanding is that the following program should compile without error as is the case with the current FTN95. There is a false warning message which will be removed for the next release of FTN95.

program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
integer j
real(kind=dp) :: x(1:n) = (/(i,i=1,n)/), y(1:n) = (/(i,i=1,n)/)
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main

The internal compiler error has now been fixed for the next release of FTN95.

As a result the compiler will set the type of the variable A to the default INTEGER type.

Thanks Paul,

I will be wary of this construction when sharing code with those using alternative compilers.