/check and sub-arrays

I occasionally have problems compiling with /check, when sub arrays are used. In the following example, the 4th argument is declared as integer, dimension(2), but supplied as a part of an integer array iilist(6:7). This all works well (with /debug) unless /check is used. When running the program, there is an error 'Attempt to call a routine with argument number four containing too few argument elements'. I overcame the problem, by declaring the array as variable length then reporting the size of the array, which was always 2. As the dimension was declared 'dimension(: )', I also used an interface declaration in all calling routines.

Is this a bug in /check, not being able to recognise 'iilist(6:7)' is dimension 2 ?

( I'm also getting another 'Error: ALLOCATE was unable to obtain sufficient storage' when trying to allocate an integer*4 array of dimension (5);( 20 bytes! ), after a combined ALLOCATE of 1.58 mb in 4 other arrays, but that is another puzzle )

John

! typical call to routine
       call fix_Beam_release_code (0, etype, jk, iilist(6:7))

      subroutine fix_Beam_release_code (ftype, etype, jk, end_code)
!
!  First declaration
         integer*4 ftype, etype, jk(6,2), end_code(2)
!
!  Revised declaration
         integer*4,                 intent (in)    :: ftype        ! format type
         integer*4,                 intent (in)    :: etype        ! element formulation type
         integer*4, dimension(6,2), intent (in)    :: jk           ! end release code for ftype=5, etype=2
         integer*4, dimension(:),   intent (inout) :: end_code     ! end release code

John,

If the subroutine only uses two elements from the passed array, then it was probably alright to use a dimension of 2 within the subroutine. In the calling statement, you only need to refer to the first element position as it is simply the address of the start of the section of the array you wish to use.

For example,

       call fix_Beam_release_code (0, etype, jk, iilist(6)) 

       subroutine fix_Beam_release_code (ftype, etype, jk, end_code) 
       integer*4 ftype, etype, jk(6,2), end_code(2) 

should work, but whether /check fouls this up, I do not know.

Regards

Ian

Are you using an interface in the code that calls the subroutine?

Paul,

My first attempt, which failed, did not use an interface block.

In all cases, the calling list was the same: ' call fix_Beam_release_code (0, etype, jk, iilist(6:7)) '

The first attempt which failed had the subroutine defined as a F77 style: ' subroutine fix_Beam_release_code (ftype, etype, jk, end_code) ! integer*4 ftype, etype, jk(6,2), end_code(2) '

It appears that the supplied argument 'iilist(6:7)' did not work with the definition of 'end_code(2)'

By going to the implied size and using an interface block, this solved the problem.

Perhaps I could have also solved the problem with F77 style by declaring Integer ecode(2) Equivalence (iilist(6), ecode(1)) Then using ecode as an argument.

FTN95 appears to object to the 4th argument as iilist(6:7); an array argument. My question is, is this array argument inconsistent with the 'integer end_code(2)' when /check is used ?

I was actually trying to use /check to verify other parts of the code, but /check caused problems with this approach to sending part of the array. I thought that using iilist(6), as Ian has suggested, would also be wrong when /check is used. However, I tested this and it worked !

I am now getting the error 'Error: ALLOCATE was unable to obtain sufficient storage' with very small arrays. I am using /3gb and ftn_95_new_memory=ON, with a total of 6 allocated arrays using 4k of memory. Could there be a problem with the new memory model and /check ?

There may be an error somewhere else in the program, but /check is not giving a clear indication where it is !

John

ps: Can my allocate problem be from using the new memory model and /check ? I thought I would still get 2gb with /check but somewhere I am running out of memory/storage. When using /check, does DEALLOCATE not release the memory? I don't think it is a stack size problem, as I think ALLOCATE does not use the stack memory area. Any comment ?

Hi John

I am sorry to say that your question is too long and complex for me to handle right now. Can you run a test with the latest download (5.30) and then, if the problem persists, let me have some sample code together with a short and simple query.

Regards

Paul