Automatic Arrays as Argument

Is it allowed to pass an array section of an automatic array to another subroutine? The problem is illustrated by the attached program “Automatic_Array”. In the present case, the program stops with an error message, but I have also seen similar cases, where the program failed because of undefined variables. Can anybody help?

Many thanks,

Klaus Lassmann [code] Winapp

Program Automatic_Array

Implicit None
Real    , Dimension ( 3 )   :: x
Integer                     :: n

x (1) = 1.
x (2) = 2.
x (3) = 3.

n = 3

Call SubA ( x (1:n) , n )

! #########

End Program Automatic_Array

Subroutine SubA ( xData, npoint )

  Implicit None
  Real , Dimension (npoint) :: xData
  Integer                   :: npoint, mpoint
  
  Real , Dimension (npoint) :: yData  ! Automatic object

  yData = xData * 2.

  Write (*,*) ' xData = ', xData
  Write (*,*) ' yData = ', yData

  mpoint = 2

! This call leads to an error:

  Call SubB ( yData (1:mpoint), mpoint )

! This call gives the correct solution

! Call SubB ( yData , mpoint )

End Subroutine SubA 

Subroutine SubB ( x , m)

  Real , Dimension (m) :: x
  Integer              :: m

  x  = x * 0.5

  write (*,*) 'y      = ', y

End Subroutine SubB

[/code]

Klaus,

Using Ftn95 Ver 5.30.0 with SubB changed to 'write (,) 'x = ', x'; It compiles and runs with 'ftn95 kl.f95 /debug', but gets an error with 'ftn95 kl.f95 /check' 'Attempt to call a routine with argument number one containing too few array elements' I also tried to include an interface definition for SubB in SubA (see below), but that did not fix the problem. I would consider this a 'bug', which I am very familiar with and we have seen this problem recently. From memory, the problem is that Ydata is transferred as having zero size. There is a problem with sub arrays and /check. It may be only for sub arrays of automatic arrays. I had a quick look through past posts but could not find the latest post and a response. I'm not sure if it has been fixed with Ver 5.40. This is certainly a good small example of the problem. Program Automatic_Array

 Implicit None 
 Real , Dimension ( 3 ) :: x 
 Integer :: n 

 x (1) = 1. 
 x (2) = 2. 
 x (3) = 3. 

 n = 3 

 Call SubA ( x (1:n) , n ) 
! ######### 

End Program Automatic_Array 

Subroutine SubA ( xData, npoint ) 

 Implicit None 
 Real , Dimension (npoint) :: xData 
 Integer :: npoint, mpoint 

 Real , Dimension (npoint) :: yData ! Automatic object 
! Real , allocatable, Dimension (:) :: yData ! Allocatable object 
! Real , Dimension (3) :: yData ! local array

!interface
! Subroutine SubB ( x , m) 
!  Real , Dimension (m) :: x 
!  Integer :: m 
! end Subroutine SubB
!end interface

! Allocate (ydata(npoint))

 yData(1:npoint) = xData * 2. 

 Write (*,*) ' xData = ', xData 
 Write (*,*) ' yData = ', yData 

 mpoint = 2 

! This call leads to an error: 
 Call SubB ( yData (1:mpoint), mpoint ) 

! This call gives the correct solution 
! Call SubB ( yData , mpoint ) 

End Subroutine SubA 

Subroutine SubB ( x , m) 

 Real , Dimension (m) :: x 
 Integer :: m 

 x = x * 0.5 
 write (*,*) 'x = ', x

End Subroutine SubB 

Update:

1. updating FTN95 to Ver 5.40.0 did not fix the problem.
2. converting from Automatic arrays to Allocatable arrays did fix the problem, so there is still a problem, unique to automatic arrays.
3. local arrays also work fine

John

Update-2 I used the updated SDBG.exe from Robert, of 13-Oct-09, and after the program crashed on entry to SubB, I moved through the stack to find that the 'Vars' window correctly shows M=2, X is dimensioned (2) and the values in X are correct. The recent update of SDBG is showing the correct size for array X, but the 'Call Stack/Status' is reporting the error.

This bug replicates two others that have been reported elsewhere. i.e. on review it turns out that this bug has already been fixed for the next release.

Paul, this is very good news. Thank you very much for your efforts.

Klaus