 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
KL
Joined: 16 Nov 2009 Posts: 155
|
Posted: Mon Nov 16, 2009 6:44 pm Post subject: 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] |
|
Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Tue Nov 17, 2009 1:38 am Post subject: |
|
|
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. Code: | 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. |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8210 Location: Salford, UK
|
Posted: Wed Jul 21, 2010 8:13 am Post subject: |
|
|
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. |
|
Back to top |
|
 |
KL
Joined: 16 Nov 2009 Posts: 155
|
Posted: Wed Jul 21, 2010 12:00 pm Post subject: |
|
|
Paul, this is very good news. Thank you very much for your efforts.
Klaus |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|