forums.silverfrost.com

[KL]

I have problems in passing integer variables through several subroutines in a specific system of subroutines. The integer variables are part of a module, are defined and are used in several subroutines that use the module. The reason why these integer variables are passed through some subroutines as arguments is that this is an independent system of subroutines where I cannot use the module. The rules for the INTENT attribute are

INTENT(IN) The procedure must not change the argument.
INTENT(OUT) The argument is undefined on entry and may be given a value in the procedure.
INTENT(INOUT) The argument may be given a value in the procedure.

Metcalf et al. adds that a dummy argument with INTENT(IN) must not be redefined by the procedure or by being passed on as an actual argument to a procedure that redefines it. So the rules are pretty clear.

I have tried several variants: first without the INTENT attribute, then with other settings. Always an error is reported. Are there further rules for such a situation?

Two results:

If I set in the last subroutine to which the variables are passed

[LitusSaxonicum]

Klaus,

Have you tried this with a simple example code? I had a go:

[KL]

Dear Litus,

thank you very much for your quick reply. Of course I have checked everything carefully not only for hours but for days. But you certainly know that once you have overlooked something it is difficult to find. I�ll try tomorrow again.

One thing puzzles me: In the development phase I normally compile my program with the options /checkmate /Full_Debug. With these options I get the reported error messages. If I run the program without these options, the (rather big) program runs fine.

I have tried to demonstrate this problem with a small code, but up to now I failed to exactly reproduce this error. However, with the following program I observe also a strange effect:

With the compiler options /checkmate /Full_Debug I get the error message

[davidb]

I have encountered problems using internal subroutines that access a subroutines arguments by host association. This may be the cause of the problem. I don't have a simple example right now though, but if I get time I will post one.

It is not clear to me whether the subroutines that are outside the module (which have an implicit interface) are allowed to use INTENT without an explicit interface being created using an INTERFACE block.

[PaulLaidler]

Klaus

I have had a look at the access violation produced by the program that you have posted above.

/check (and anything that implies /check) produces runtime checking of subprogram arguments (in addition to other checks both at compile time and at runtime). There are currently 14 types of checks and particular types can be inhibited with /inhibit_check n (where n is in the range from 1 to 14 inclusive).

The complexity of your code (though valid) has been too great for both type 5 and type 10 of the checking types which happen to be runtime checks on the arguments passed. In other words /check is very useful but apparently cannot handle the kind of complexity that you are aiming to use.

It is possible that we might be able to improve /check in order to handle this degree of complexity but in the meantime, when using /check with this code, you will also need to use

/inhibit_check 5 /inhibit_check 10

You will understand that /check provides additional tests during development. The fact that you miss out on a couple of these tests is not that important once you are happy that the arguments are being passed correctly.

[KL]

Paul,

I cannot see that such a structure is too complex. Just imagine a solver for a linear set of equations. This is exactly what is behind my example, namely a standard solver for a pentadiagonal system. Traditionally, we call inside a Fortran program 2 external subroutines: One is performing the decomposition and the other the rest. Inside these subroutines are exit conditions, sometimes just a stop. Fortran 95 with its possibility of having internal subroutines offers a much simpler structure. In my case of a pentadiagonal system the standard routine consists of a driver which calls the two external subroutines. Why not putting these 2 external subroutines as internal subroutines in the driver? The result is a single and well structured subroutine. Instead of 3 argument lists we get only one. Of course it must be possible to exit from an internal subroutine and pass some variables to an external subroutine which deals with the stop condition. By the way, this new formulation has been tested successfully by 1000000 random test cases in a specific test environment but fails in a larger code.

From this problems and from past experience I get the impression that the debugger has in few specific circumstances problems with the full range of Fortran 95 possibilities. Since we all know about the tremendous importance of the debugger within the development of large code systems, I would like to express my strong interest in any further development of the debugger.

Best regards,

Klaus

[PaulLaidler]

I have not explained this situation very well. The Fortran code is good but the existing runtime checking provided by FTN95 and salflibc.dll is not clever enough to handle your code. The problem does not involve the debugger SDBG.

Runtime checking of arguments passed to subprograms is a non-trivial operation for a language like Fortran 95. The people who wrote FTN95 have had a good go at it but /check still cannot handle everything that the the Fortran standard allows. /check is a useful tool not normally provided by other compilers so in that sense it is a bonus and it works in most cases. When it does not work, you can switch it off locally or use /inhibit_check.

Having said all of this, I will try to fix this particular problem.

[PaulLaidler]

I have not explained this situation very well. The Fortran code is good but the existing runtime checking provided by FTN95 and salflibc.dll is not clever enough to handle your code. The problem does not involve the debugger SDBG.

Runtime checking of arguments passed to subprograms is a non-trivial operation for a language like Fortran 95. The people who wrote FTN95 have had a good go at it but /check still cannot handle everything that the the Fortran standard allows. /check is a useful tool not normally provided by other compilers so in that sense it is a bonus and it works in most cases. When it does not work, you can switch it off locally or use /inhibit_check.

Having said all of this, I will try to fix this particular problem.

[KL]

Thank you very much for your explanations, Paul. Indeed, I was not really aware of the difference between runtime checking and debugger. I agree with your arguments about runtime checking. However, the problem is that if you get an error message which clearly says that something is wrong, you look first in your code. In my case for days.

Since I am now aware of some shortcomings of the runtime check utility, I can of course live with it. Saying this I would nevertheless appreciate a review of the runtime checking tool, especially with view on misleading error messages.

Best regards,

Klaus

[PaulLaidler]

I have fixed this bug for the next release.

[KL]

Paul,

thank you very much. Will this correction be part of FTN 6.10, which has not released yet?

Klaus

[PaulLaidler]

No. 6.10 has already been released.