I am using the FTN95 compiler since many years, which I use via batch files or by two IDEs: Plato and Visual Studio 2015 Community. Unfortunately, I have experienced from time to time unexplainable errors during the recent years. Today, I have some hope that I am at least close to the source of the problem. Let me try to explain.

I work with FTN95 Personal Edition 8.10, Plato 4.81 and Visual Studio 2015 Community 14.0.25431.01 Update 3. I know that passing an array to a subroutine as dummy argument by reference or passing an array section is not identical, but I would expect that passing an array a, dimensioned by (n,n), should give identical results as passing the “array section” a(1:n,1:n).
The programme test92 does the following:

-Array sections a(1:n), b(1:n,1:n) are passed from main to sub1 and sub2.
-The logical variable “fail” is passed back from sub2 and sub1 to main.
-The automatic array c is defined in sub2 and passed back to sub1.

I have constructed this completely pointless demo to investigate some areas where I have experienced problems. And indeed:
As expected, the programme test92 runs for all Plato compiler options (Checkmate .Net etc., 9 in total) as well as for all Visual Studio options except for Checkmate Win32. This option gives the following error messages:

I just would like to mention that under Visual Studio the switch from win86 to win64 does not really work as expected.

The errors are caused by line 85. If this line is commented out and either line 86 or line 87 are used, the error disappears.
Can anybody confirm my findings, or is there an error in my programme, which everybody but me sees?

Klaus

PS. How can I send the three pdf files???

[code:1:c8e495571d]

winapp

Program test92

! Array sections a(1:n), b(1:n,1:n) are passed from main to sub1 and sub2
! Logical variable fail is passed back from sub2 and sub1 to main
! Automatic array c is defined in sub2 and passed back to sub1

I thought similarly to Paul. I suspected you returned the automatic array, linked via a pointer, but in FTN95, like local allocatable arrays, automatic arrays are lost on return. After return, the pointer array can still be used (incorrectly).
The only way to allocate and retain arrays in FTN95 is to store them in a MODULE.
I find Fortran standards vague in their definition of scope of names, especially identifying what compilers must do vs what they may do when names go out of scope. Most compilers are more friendly that the Standard.

on about line 85. You don't need the array section (for c) at this point since you are using the whole array.

I don't know at the moment if this is a bug in the check mechanism.

As a general rule you should not pass array sections unless you have to. The compiler will usually plant code to pass a copy of an array section (sometimes both in and out) and there is naturally an associated overhead.

Thank you very much for your quick answer, Paul. I agree and I am aware of the overhead.

I had already found two other workarounds: please see lines 86 and 87 (I am not sure whether I tested both in the latest version).

Although there is an easy workaround and a clear, simple and convincing recommendation, I would suggest to further investigate this case. The more since program test92 runs within Plato and Visual Basic successfully with 8 other options: Checkmate .NET, Checkmate x64, Debug .Net, Debug Win32, Debug x64, Release .NET, Release Win32, Release x64. These options differ in checking rules or providing an executable for different architectures, but all conform to the same Fortran rules.

The fact that it runs for Checkmate x64 and CheckMate .NET is significant and implies a bug in CheckMate Win32. The other configurations would not generate this runtime error even if the Fortran source were faulty.