forums.silverfrost.com

[jayxwang]

Dear Sir or Madam,

In FEA program, a lot of REAL and INTEGER variables are often stored in a 1-D REAL array, say in an array called A(K) for data passing. The part of the integer numbers stored in A must be passed around in the FEA program in different places to some INTEGER arrays (1-D or 2-D), say ML(M,N), by calling some specific subroutines.

FORTRAN 77 allows this kind of data exchange between a REAL array and an INTEGER array. I guess FORTRAN 95 also allows it. But when using FTN95 to compile the progam, link problems always come up with error message like this:

"SUBROUTINE 'XXXX' called with argument no 3 as a REAL(KIND=1) when a INTEGER(KIND=3) was expected (from SUBROUTINE 'YYYY')"

Does it mean that the arguments for data passing have different lengths?

Thanks in advance.

[davidb]

It is illegal Fortran (Fortran 77 and Fortran 95) to call a subroutine with a REAL actual argument when an INTEGER dummy argument is expected.
(If you are compiling separate files, this is picked up by the Linker. If you put the routines in one file, the compiler should give an error.)


You can't do the following, for example:

[Sebastian]

[JohnCampbell]

The method of memory management you describe predates ALLOCATE, which was introduced in Fortran 90.
There are many programs, including my FEA program which still use these methods successfully. Many public domain programs were developed in 70's and 80's using this approach and they are still in use today.
There are many tricks that can be used to overcome the problem you have found.
1) The easiest is to not use /check when you compile and the problem will go away.
2) You could try to convert the memory management to using ALLOCATE, although ALLOCATE does not easily support resizeing arrays, such as when you allocate a "big" array then resize it after you know how big it needs to be. There are many things that ALLOCATE is good at but this in not one of them. Any change involving ALLOCATE involves significant re-programming.
3) Involving even more re-programming is using a MODULE of all key arrays and making these arrays ALLOCATABLE. This is the neatest approach.
4) If you want to keep using /CHECK and minimise your changes, you can use two arrays and equivalence them. The problem you need to check is when the program was written. If it uses INTEGER*4 and REAL*8 then it may have addressed the problem that real*8 is 8 bytes and integer*4 is 4 bytes. An example code that could be used is

[jayxwang]

Many Thanks to davidb, Sebastian and John. Special thanks for John for his sigificant amount of time and attention and great solutions to the problem.

John: Visual FTN95 is brand new for me. Where can I turn off "/check", please?

[JohnCampbell]

I don't use Visual Studio, so don't know if Check, Debug or Production are 3 compilation modes available to be selected. I think they are somewhere. (someone else may be able to help)

The basic problem you are identifying is that it would be good to have a modified /check available for the other parts of the code, except for:
1) argument type checking is ignored,
2) upper bound checking of arrays is ignored only for arrays dimensioned (*) or (1), but lower bound checking is maintained (subscript < 1)

I did get that change in some compilers in 80's but in general most compiler developers are reluctant to consider this programming method.

It's a shame, as I think there is still a significant number of programs which use this memory approach and ALLOCATE does not easily cope. The main area is when reading data where you do not know the number of active elements. You first allocate a large array, then once read, the array can be re-sized smaller and the balance of memory returned to the memory pool. It is possible to do this legally with ALLOCATED arrays by allocating a temporary array, copying then re-allocating the original array, but it is difficult if the start of the main array is an argument to the working routine.

Another for the wish list !

John

[PaulLaidler]

When using either Visual Studio or Plato you can configure the compiler for /check etc from the main toolbar. At the same time you can select between .NET and Win32.

Alternatively, from the FTN95 command line you can use /check etc.

/check has various components that can be selectively switched off by using /inhibit_check <integer> on the command line but the details are not documented so it is a case of trial and error to see which <integer> is needed. However, in your case it looks like you need /inhibit_check 5

/check can be applied (or not) on a file by file basis or even for different routines by using the OPTIONS directive in the code. You might be able to apply /inhibit_check 5 gloabally by configuring the compiler via /config.

[PaulLaidler]

I do not have time right now to provide documentation for /inhibit_check but here is the information that I have...

[JohnCampbell]

Paul,

Thanks very much for the list.

Option 5 - suppress the argument type/size checking on function entry
For me, this is a key aspect of looking for program errors. I would like to suggest that this could be improved a lot.

I don't know how many others experience the programming errors I do, but I find that "Type" and "size" checks are very different aspects.
I'd like an option to exclude type but keep size checks. This would allow /check to be used in a lot of cases and cope with pre-90 programming techniques, where type mixing was often used. My variable length record disk random I/O library is a good example of where this can be applied, where I am transferring a memory record address and byte length.

The most common size error I have encountered is having a subscript = 0; which typically occurs if it is not defined or references data that is not provided.
It would be good to have a size check option for subroutine argument arrays dimensioned as either:
INTEGER AA(*), BB(1)
When applying size check to these arrays, the lower bound check is included (index < 1) but no upper bound check is applied.

This may already be the case?

Does the /BOUND_CHECK option still work or has it's functionality been replaced by /CHECK? I recall a post that some of these compiler checking options are no longer supported.

John

[PaulLaidler]

/bounds_check is still implemented and, according to the documentation, it checks array subscripts only. It is included in /check.

I can add your request to the wish list but it would probably be quite tricky to implement.

[JohnCampbell]

Paul,

I'm pleased to hear than /BOUNDS_CHECK is still implemented. It may be only in my memory that it isn't !

I described a bit of functionality in my last post. Could you clarify what checks are done with /bound_check for array declarations of the type "INTEGER AA(*), BB(1) ". Having a lower bound check available would be good, as I find undefined subscripts can be the most common problem.
Is this the case ?

John

[PaulLaidler]

The easiest way to get this information is by trial and error.
If you find anything useful then let me know and I will add it to the documentation.