Problem: “Problem Array Section with /Checkmate”

Hi, In regards to the error: 'Attempt to call a routine with argument number XX containing too few array elements' when using \check

I've been getting the same error. Lets say when program main calls subroutine SubA which calls subroutine SubB. With arrayx being passed to each. Arrayx initially declared in Program Main. Also, Subroutine SubB recieves some truncated version of arrayx (in my case one dimension less)

I.e.

Program main bla bla CALL subA(arrayx(:,:),n1,n2) End Program main

Subroutine SubA bla bla CALL subB(arrayx(i1:i2,1),n)** !ERROR**

End subroutine SubA

a work around is to call subB as:

CALL subB(arrax(i1:i2,1:1),n)

For me this causes the error to go away. I have no idea why, but hope it helps.

Laurence

Paul,

Lately I've been using /check more often and this error keeps coming up. The length of the array section is not being correctly transferred, but if I step up the stack in the debugger, all the info is available in the array with the correct dimension, although I assume the problem is that /check says the supplied array is not 4 long. I've cut the following example from my code.

      INTEGER*4 SEC_TYPE, UPROP(13)
      REAL*8    TPROP(13)
!
      tprop = 0
      tprop(9:10) = .100
      tprop(11:12) = .005
      call SECTION_PROP (SEC_TYPE, TPROP, UPROP)
      end

      SUBROUTINE SECTION_PROP (SEC_TYPE, TPROP, UPROP)
!
!    calculate section properties for generic section type
!
      INTEGER*4 SEC_TYPE, UPROP(13), I
      REAL*8    TPROP(13)
      real*8    angle_props(9)
!
      call get_angle_props (tprop(9:12), angle_props)
!
  100 RETURN
!
      END SUBROUTINE SECTION_PROP

      subroutine get_angle_props (dimen, props)
!
!    calculate the properties of an (un)equal angle
!
      real*8    dimen(4), props(9)
      REAL*8    AX,AY,AZ, B,D,T,W, B1,D1
!
!---  CHECK IF GIVEN AS A SECTION TYPE
!
      D = dimen(1)
      B = dimen(2)
      T = dimen(3)
      W = dimen(4)
!
      D1 = D-T
      B1 = B-W
!
!   Area
      AX = D*W + B1*T
      AY = D*W
      AZ = B*T
!
      props(1) = ax                        ! ax
      RETURN
      END

Thanks. The bug is still outstanding and I hope to have it fixed before too long.

Sorry for the delay in getting back to you on this bug. Having finally revisited the problem I find that the bug has been reported elsewhere and is now fixed. The fix will in the next release.

Paul,

That is great news. I will be keen to get the update and get past this point. I have had to avoid /check for these routines. Can you give any summary as to why these arrays lost their size attribute?

John

As I understand it, the size attribute was not lost (is there evidence that it was?).

Run time checking of array sizes turns out to be very difficult (maybe impossible with the current design for runtime checking) for array sections of varying size. The fix is to switch off this aspect of /check in this particular case.

Paul,

I thought it was lost, but now it is found ?? If you take the example I provided above and compile with /check and step in SDBG, at 'call get_angle_props (tprop(9:12), angle_props)' SDBG claims the dimension of 'tprop(9:12)' is not 4. I have NOW modified the program. Try this modified program below using /check and step through SDBG and it shows a dimension of 1 for dimen and 9 for props ?

      INTEGER*4 SEC_TYPE, UPROP(13)
      REAL*8    TPROP(13)
!
      tprop = 0
      tprop(9:10) = .100
      tprop(11:12) = .005
      call SECTION_PROP (SEC_TYPE, TPROP, UPROP)
      end

      SUBROUTINE SECTION_PROP (SEC_TYPE, TPROP, UPROP)
!
!    calculate section properties for generic section type
!
      INTEGER*4 SEC_TYPE, UPROP(13), I
      REAL*8    TPROP(13)
      real*8    angle_props(9)
!
      call get_angle_props (tprop(9:12), angle_props)
!
  100 RETURN
!
      END SUBROUTINE SECTION_PROP

      subroutine get_angle_props (dimen, props)
!
!    calculate the properties of an (un)equal angle
!
!      real*8    dimen(4), props(9)
      real*8    dimen(*), props(*)
      REAL*8    AX,AY,AZ, B,D,T,W, B1,D1
      integer nd, np
!
      nd = size (dimen)
      np = size (props)
!
!---  CHECK IF GIVEN AS A SECTION TYPE
!
      D = dimen(1)
      B = dimen(2)
      T = dimen(3)
      W = dimen(4)
!
      D1 = D-T
      B1 = B-W
!
!   Area
      AX = D*W + B1*T
      AY = D*W
      AZ = B*T
!
      props(1) = ax                        ! ax
      RETURN
      END

I am guessing a little here but you probably need an interface together with the corresponding change in the definition of the subroutine...

      interface
      subroutine get_angle_props (dimen, props) 
      real*8    dimen(:), props(:)
      end subroutine
      end interface

I suspect that there will be something in the standard that says you have to do this (i.e. use assumed-size arrays). If this is not the case, let me know and I will look it up.

Paul,

I did have the declaration of : real8 dimen(4), props(9) I changed it to: real8 dimen(), props() So that I could get through the subroutine call with /CHECK

  nd = size (dimen)    !  gives an incorrect value of 1
  np = size (props)     ! gives a correct value of 9

For either declaration, I don't think I need an INTERFACE The problem is that the size of DIMEN is being provided incorrectly for /CHECK. Does the latetest fix address this problem ?

I only need this so /CHECK works past this point. I thought my possible problems that require /CHECK are not with this routine.

John

If you provide the interface for get_angle_props in the definition of sectin_prop then SDBG reports the sizes correctly.

The interface tells the compiler that the shapes of the arrays must be passed together with the base addresses. Otherwise get_angle_props does not receive the shapes of the arrays.

I can get the compiler to trap the explicit call to SIZE for a 'star-sized' array but I don't know if anything can be done to 'fix' SDBG in this context.

Paul,

Sorry to continue with this; My understanding is that 'No shape' is required as they are both vectors, although we do need their size, which I assume /check provides. When compiling with /check, the call 'get_angle_props (tprop(9:12), angle_props)' needs to say that 'tprop(9:12)' is a vector of length 4 and 'angle_props' is a vector of length 9. The length 4 is not being correctly provided. The value of nd = size(dimen) gives a value of 1.

Is 'call get_angle_props (tprop(9:12), angle_props)' the same as 'call get_angle_props (tprop(9:12), angle_props(1:9) )' ? Or am I wrong in assuming angle_props means the same as angle_props(1:9) as a subroutine argument ?

It is my assumption that tprop(9:12) should be equivalent to a real*8 1-dimensional array of length 4, but that is not happening. Am I wrong in assuming this ? I thought array sections were themselves arrays.

I again changed the program, and ran it on Ver 4.9.1 with /check /lgo and got some interesting results:

      INTEGER*4 SEC_TYPE, UPROP(13) 
      REAL*8    TPROP(13) 
! 
      tprop = 0 
      tprop(9:10) = .100 
      tprop(11:12) = .005 
      call SECTION_PROP (SEC_TYPE, TPROP, UPROP) 
      end 

      SUBROUTINE SECTION_PROP (SEC_TYPE, TPROP, UPROP) 
! 
!    calculate section properties for generic section type 
! 
      INTEGER*4 SEC_TYPE, UPROP(13)
      REAL*8    TPROP(13) 
      real*8    angle_props(9) 
! 
      call get_angle_props (tprop, angle_props, 'tprop, angle_props ') 
      call get_angle_props (tprop, angle_props(1:9), 'tprop, angle_props(1:9) ') 
      call get_angle_props (tprop(1:13), angle_props, 'tprop(1:13), angle_props ') 
      call get_angle_props (tprop, angle_props(4:6), 'tprop, angle_props(4:6) ') 
      call get_angle_props (tprop, angle_props(2:7), 'tprop, angle_props(2:7) ') 
      call get_angle_props (tprop, angle_props(1:6),  'tprop, angle_props(1:6)  ') 
      call get_angle_props (tprop(1:13), angle_props(4:6), 'tprop(1:13), angle_props(4:6) ') 
      call get_angle_props (tprop(1:), angle_props(5:), 'tprop(1:), angle_props(5:) ') 
      call get_angle_props (tprop(1:8), angle_props(4:6),  'tprop(1:8), angle_props(4:6) ') 
      call get_angle_props (tprop(4:8), angle_props(4:7),  'tprop(4:8), angle_props(4:7) ') 
! 
  100 RETURN 
! 
      END SUBROUTINE SECTION_PROP 

      subroutine get_angle_props ( dimen,  props, desc ) 
! 
!    calculate the properties of an (un)equal angle 
! 
      real*8    dimen(*), props(*) 
      character desc*(*)
      integer nd, np 
! 
      nd = size (dimen) 
      np = size (props) 
      write (*,*) 'nd = ',nd,'  np = ',np, '     ', desc
! 
      RETURN 
      END 

The local array 'angle_props' is treated differently that the argument array 'tprop' It would appear that any angle_props(3:y) gets the same length, irrespective of the value of y, while any value of tprop(x:y) gets a length of 1 To me this shows that /check is not including the correct length

John

run results are [FTN95/Win32 Ver. 4.9.0 Copyright (C) Silverforst Ltd 1993-2005]

    NO ERRORS  [<main program> FTN95/Win32 v4.9.0]
0014)       INTEGER*4 SEC_TYPE, UPROP(13)
WARNING - The argument SEC_TYPE has not been used
WARNING - The argument UPROP has not been used
0029)   100 RETURN 
WARNING - Label 100 is declared, but not used
    NO ERRORS, 3 WARNINGS  [<SECTION_PROP> FTN95/Win32 v4.9.0]
    NO ERRORS  [<GET_ANGLE_PROPS> FTN95/Win32 v4.9.0]
Creating executable: C:\\John\\test\\lgotemp@.exe
Program entered
 nd =           13  np =            9     tprop, angle_props 
 nd =           13  np =            9     tprop, angle_props(1:9) 
 nd =            1  np =            9     tprop(1:13), angle_props 
 nd =           13  np =            6     tprop, angle_props(4:6) 
 nd =           13  np =            8     tprop, angle_props(2:7) 
 nd =           13  np =            9     tprop, angle_props(1:6)  
 nd =            1  np =            6     tprop(1:13), angle_props(4:6) 
 nd =            1  np =            5     tprop(1:), angle_props(5:) 
 nd =            1  np =            6     tprop(1:8), angle_props(4:6) 
 nd =            1  np =            6     tprop(4:8), angle_props(4:7) 

John,

You need to change from assumed-size arrays (star sized) to assumed-shape arrays (using a colon). You also need to include the interface that I have posted. If you do this then you will get the correct results.

Even a vector has shape and this must be passed to get_angle_props. The interface makes this happen.

I have now added code to the compiler to trap the error when SIZE is called for an assumed-size array where the DIM is equal to the rank.

Paul,

I disagree with the approach you are taking. If I take you back to my original problem where ftn95 /check is not providing the correct argument sizes.

I have a subroutine defined as
subroutine get_angle_props ( dimen, props) real*8 dimen(4), props(9) ...

The info for dimen(4) is taken from part of a larger array. If I use the old style ftn call I would have the call ' get_angle_props (tprop(9), angle_props) ' and all runs ok.

The problem came when I wanted to check the program and tried to use /check to see if there were any problems in other parts of the program. The error came back that the supplied array was too small.

To overcome this I had two easy options, I could define a temporary array 'real*8 dimen(4)' to use in the call and define it by 'dimen = tprop(9:12)' Alternatively, I thought I could show /check that the array had 4 elements by using the array section in the call as ' get_angle_props (tprop(9:12), angle_props) ', which minimises the changes to the original code. I am trying not to put lots of temporary array patches through my code.

I do not see why calling the routine ' get_angle_props ' needs an interface, as the dimensions expected are clearly defined and this extra info is only required by /check. You appear to be saying I need an interface so that /check can work. /check should be able to recognise that 'tprop(9:12)' is an array of 4 elements.

In the example I posted last night, 'IF' SIZE is working with the declaration ' real8 dimen(), props(*) ' then 'ftn95 /check' is supplying incorrect information about the size of the arguments. (The use of SIZE is the only way I could see how to easily report the array sizes provided by /check. If I don't compile with /check the size is not available)

Indeed, in SUBROUTINE SECTION_PROP, any array section of the supplied (dummy argument?) array 'tprop' appears to be given a length of 1, while any array section of the local array 'angle_prop' appears to ignore the defined end, eg angle_prop(3:5) is compiled as angle_prop(3: ).

It is my impression that

1. /check should be able to provide the array size, being 4 for the array section 'tprop(9:12)' .
2. We should not have to provide an INTERFACE just for /CHECK to work.

I have been assuming that when compiling with /CHECK, extra information is provided on the stack about the supplied subroutine arguments and in this case it is not being done correctly.

John

Further,

If I modify the routine so that an interface is required, all works using

      INTERFACE
         subroutine get_angle_props (dimen, props) 
         real*8    dimen(:), props(:) 
         end subroutine get_angle_props
      END INTERFACE

But I can not get the INTERFACE or call to work with /check if the original subroutine is defined as subroutine get_angle_props (dimen, props) ! ! calculate the properties of an (un)equal angle ! real8 dimen(4), props(9) REAL8 AX,AY,AZ, B,D,T,W, B1,D1 ! ...

This simple definition should not be incompatible with /check and it should not be reported that tprop(9:12) is the wrong size, which is saying that /check does not support array sections.

John

Perhaps it would be simpler to wait till you see the next release. As I have noted earlier in this thread, I agree that /check was not working for array sections (it was reporting the wrong size). For the next release I have fixed this problem by changing the compiler so that it does not provide data for the runtime check in this particular case. (i.e. this check is not carried out, allowing the executable to run naturally).

With the current release, if you use assumed-shape arrays and the interface then SDBG should show the correct sizes but the runtime checking will cause it to fail. i.e. the compiler sizes (via the shape that is passed) will be correct but the runtime checking values will be wrong.

As I say, lets leave this till you see the fix that I have provided for the next release.

Paul,

Thanks for that. I'll look forward to the next update.

John