forums.silverfrost.com

[KL]

The attached program looks terrible. However, it reflects the structure of a �real� program, where I found the problem. The problem occurs when running the program with the /Checkmate option, which I almost always use:

ftn95 Problem_Array_Section.f95 /Checkmate /underflow /Link >> comp.lis
sdbg Problem_Array_Section.exe

The error message is
�Attempt to call a routine with argument number two containing too few array elements�

The reason why I chose this form is because in the real problem the indices of array x (1,2,3..) in subroutine SubB correspond to indices 2,3,4 of array Data in subroutine SubA. For this transformation I need the array section as argument.

Is anything wrong with the program? Can anybody comment on this problem?

Many thanks,

Klaus Lassmann
[ Winapp

Program Problem_Array_Section


Implicit None
Integer :: i, n

Real , Dimension (400) :: Result

n = 3

! Subroutine SubA calculates with the help of SubB the field Result

Call SubA ( Result, n )
! #########

Write (*,*) ' Result (1,n)= ', ( Result (i), i=1,n )

Contains

Subroutine SubA (Data, m)

Implicit None
Integer :: i
Integer , Intent (in ) :: m
Real , Dimension (m), Intent (out) :: Data

! --- This call leads to an error when compiled with /Checkmate:

Call SubB ( m, Data (1:m) )

! --- This call seems to be OK

! Call SubB ( m, Data )

Write (*,*) ' Data (1,m) = ', ( Data (i), i=1,m )

End Subroutine SubA

End Program Problem_Array_Section

! --------------------------------------------------------------------

Subroutine SubB ( k,x )

Implicit None
Integer , Intent (in ) :: k
Real , Dimension (k), Intent (out) :: x
Integer :: i

Do i = 1, k
x(i) = i**2
End Do

End Subroutine SubB

]

[JohnCampbell]

Paul,
This second example shows that errors associated with array sections in subroutine arguments when compiled with /check are not limited to automatic arrays. The program works ok with /debug.
As I have found before, if I use array sections, I can not debug using /check.
Can this be investigated ?
Thanks John

[PaulLaidler]

Yes this looks like a problem I need to look at but I may not be able to give you a quick response at the moment.

[PaulLaidler]

I have identified the problem and expect to be able to fix it in one way or another.

The only short term solution is to use /inhibit_check 5 on the command line.
You could put subB in a separate file in order to apply this only to the subroutine.

[KL]

Paul,

thank you very much for your quick reaction. For me it is easy to circumvent this problem. I guess that this problem will be solved with the next update and I will wait for it.

Best wishes,

Klaus

[JohnCampbell]

Paul,

Any update on this, as this bug has limited my use of both /check, SDBG and array sections for a number of years.
It would be a good one to clean up.

John

[PaulLaidler]

I have been working on this but it is one of those tricky ones.
I am reasonably hopeful that it will be fixed for the next release.

[IanLambley]

I'm not sure why you ever need to use the form

Call SubB ( m, Data (1:m) )

If you are passing m as a variable, then the range (1:m) is redundant.

If you argue that you may want to pass another section of the array such as Data(i:j) then this can be done as:

i=5
j=10
m=j-i+1
call SubB(m,data(i))

for example if i=5 and j=10, then the following elements are required in the subroutine: 5, 6, 7, 8, 9, 10 which is six and m=10 - 5 + 1 = 6. This statement then passes 6 elements of array "data" starting with the 5th.

All you are passing for an array is the address of the start element and if that is the very first element, i.e. data(1) or data(1,1) then you only need to pass "data" and this you have done in the part of your example that worked. Even the shape of the array can be different from one program segment to another, but care is required if it is of rank 2 or higher.

The only reason that you might want to pass data(1:m) is if you also do not pass m and use a dummy dimension and the size finction to determine the passed size. See below:

[JohnCampbell]

Ian,

I have code which is of the form

[IanLambley]

Hi John,

I assume that data is a two dimensional array and that your intent is that the subroutine deals with the two elements in positions 6 & 7 on row n.

I think that it is only necessary to pass data(6,n) to the subroutine and as it is dimensioned to two in the subroutine, then it is treated within as a one dimensional array of two elements.

I have never understood the need for the array range format described whilst passing the info. I only use the start:end format for the dimensioning of arrays where the default start element is not 1.

But of course I'm an old fashioned guy and I might have missed the introduction of this method.
Multi dimensional arrays can be tricky to pass by the method described if one is hoping to refer to a small rectangular section which does not start at (1,1,1...) That is

[JohnCampbell]

Ian,

My understanding is that when providing "data(3:4,2:3)" as an argument, then the compiler will provide a temporary array(2,2) and update it when it returns. I tested this on a recent post (see general>use of type arrays) by changing the argument, while the original array did not change, but was updated on return.
It's always difficult to stop using old Fortran, when it worked so well.

John[/quote]

[IanLambley]

John,

Wow - that is useful, I shall now have to rewrite all my software even though it works, well some of it works.

Test program where the array elements contain the subscripts in the form i*1000+j and the test subroutine negates the value so you can see the modification to the main routine data.

[IanLambley]

But of course, I wan't happy about having to pass the dimensions, so using modules, interfaces and colons gives:

[JohnCampbell]

Ian,

I changed your program, using a module to access the original data2 array. The changed program shows (to me) that there must be a copy of the sectioned array data2, being used in sub4. It would appear that all sections are placed on the stack or heap, so we should be careful when specifying sections of large arrays,
for example with dot_product (a(i1:i2), b(j1:j2)); this could be very inefficient, in comparison to vecsum (a(i1), b(j1), i2-i1+1), when i2-i1 is large. I have made this mistake in the past! and now realise why the newish code did not work well.

[JohnCampbell]

Ian,
I further changed the program to test both 2 dimension arrays and 1 dimension vectors. Based on the results, it may appear that the sub section is generated if the required array is not continuous in memory, as the 1 dimensional vector appears to change.