Problems with Checkmate-Win32

Dear colleagues,

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:

Plato: attached file Plato01.pdf

Visual Studio: attached files Visual Studio 01 and 02.pdf

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??? **

    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

      implicit none

! ------------------------------------------------------------------------------
      interface
        subroutine sub1 (aa, bb, fail)
        double precision, dimension (:)  , intent (in)  :: aa
        double precision, dimension (:,:), intent (in)  :: bb
        logical,                           intent (out) :: fail
        end subroutine sub1
      end interface
! ------------------------------------------------------------------------------

      double precision, dimension (10)    :: a
      double precision, dimension (10,10) :: b
      integer                             :: n
      logical                             :: fail

      n = 2
      a(1:n) = 1.0
      b(1:n,1:n) = 2.0
      fail = .false.

      write (*,*)
      write (*,*) ' main:'
      write (*,*) '   a   = ', a (1:n)
      write (*,*) '   b   = ', b (1:n,1:n)
      write (*,*) '   fail before calling sub1 = ', fail

! ------------------------------------------------------------------------------

      call sub1 (a(1:n), b(1:n,1:n), fail)

! ------------------------------------------------------------------------------

      write (*,*)
      write (*,*) ' main:'
      write (*,*) '   fail after calling sub1 = ', fail
      write (*,*) '   End of programme'

      read (*,*)

    end Program test92

! ==============================================================================

    subroutine sub1 (a, b, fail)
      implicit none

! ------------------------------------------------------------------------------
      interface
        subroutine sub2 (aa, bb, cc, fail)
        double precision , dimension (:)  , intent (in)  :: aa
        double precision , dimension (:,:), intent (in)  :: bb
        double precision , dimension (:)  , intent (out) :: cc
        logical                           , intent (out) :: fail
        end subroutine sub2
      end interface
! ------------------------------------------------------------------------------

      double precision , dimension (:)  , intent (in)  :: a
      double precision , dimension (:,:), intent (in)  :: b
      logical,                            intent (out) :: fail

      double precision , dimension (size(a))           :: c

      integer n
      n = size(a)

      write (*,*)
      write (*,*) ' subroutine sub1:'
      write (*,*) '   a   = ', a (1:n)
      write (*,*) '   b   = ', b (1:n,1:n)

! ------------------------------------------------------------------------------

      call sub2 ( a(1:n), b(1:n,1:n), c (1:n), fail )
!!!   call sub2 ( a, b, c (1:n), fail )
!!!   call sub2 ( a, b, c, fail )

! ------------------------------------------------------------------------------

      write (*,*)
      write (*,*) ' subroutine sub1 after call sub2:'
      write (*,*) '   c   = ', c (1:n)

    end subroutine sub1

! ==============================================================================

    subroutine sub2 (aa, bb, cc, Fail)
      implicit none

      double precision , dimension (:)  , intent (in)  :: aa
      double precision , dimension (:,:), intent (in)  :: bb
      double precision , dimension (:)  , intent (out) :: cc
      logical                           , intent (out) :: fail

      integer :: n
      n = size(aa)

      write (*,*)
      write (*,*) ' subroutine sub2:'
      write (*,*) '   aa  = ', aa (1:n)
      write (*,*) '   bb  = ', bb (1:n,1:n)

      fail = .true.
      cc = sum (aa) + sum (bb)

      write (*,*) '   cc  = ', cc (1:n)

    end subroutine sub2

PPS. Instead of pdf file:

Run-time Error

*** Error 14, Attempt to alter an actual argument that is a constant, an expression, an INTENT(IN) argument, or a DO variable

The automatic array c is defined in sub2 and passed back to sub1

Automatic arrays are local to their subprogram in Fortran 95 and so can't be passed back to the calling routine.

This may or may not be the source of the failure report. If you can supply the code for the subroutines then that would help to identify the reason for the failure.

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.

Can you place the full code via a dropbox link or similar ?

John

Sorry, that the subroutines were not supplied.

Just to clarify: the automatic array c is declared in sub1 but defined in sub2. Here are the missing subroutines:

! ==============================================================================

    subroutine sub1 (a, b, fail)
      implicit none

! ------------------------------------------------------------------------------
      interface
        subroutine sub2 (aa, bb, cc, fail)
        double precision , dimension (:)  , intent (in)  :: aa
        double precision , dimension (:,:), intent (in)  :: bb
        double precision , dimension (:)  , intent (out) :: cc
        logical                           , intent (out) :: fail
        end subroutine sub2
      end interface
! ------------------------------------------------------------------------------

      double precision , dimension (:)  , intent (in)  :: a
      double precision , dimension (:,:), intent (in)  :: b
      logical,                            intent (out) :: fail

      double precision , dimension (size(a))           :: c

      integer n
      n = size(a)

      write (*,*)
      write (*,*) ' subroutine sub1:'
      write (*,*) '   a   = ', a (1:n)
      write (*,*) '   b   = ', b (1:n, 1:n)

! ------------------------------------------------------------------------------

      call sub2 ( a(1:n), b(1:n,1:n), c (1:n), fail )
!!!   call sub2 ( a, b, c (1:n), fail )
!!!   call sub2 ( a, b, c, fail )

! ------------------------------------------------------------------------------

      write (*,*)
      write (*,*) ' subroutine sub1 after call sub2:'
      write (*,*) '   c   = ', c (1:n)

    end subroutine sub1

! ==============================================================================

    subroutine sub2 (aa, bb, cc, Fail)
      implicit none

      double precision , dimension (:)  , intent (in)  :: aa
      double precision , dimension (:,:), intent (in)  :: bb
      double precision , dimension (:)  , intent (out) :: cc
      logical                           , intent (out) :: fail

      integer :: n
      n = size(aa)

      write (*,*)
      write (*,*) ' subroutine sub2:'
      write (*,*) '   aa  = ', aa (1:n)
      write (*,*) '   bb  = ', bb (1:n,1:n)

      fail = .true.
      cc = sum (aa) + sum (bb)

      write (*,*) '   cc  = ', cc (1:n)

    end subroutine sub2

Klaus

The quick fix is write

      call sub2 ( a(1:n), b(1:n,1:n), c, fail ) 

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.

Klaus

Another thing that I notice during a quick glance through your code...

The line

      cc = sum (aa) + sum (bb) 

is strange. The right hand side is a scalar so you don't need to evaluate it more than once. At the moment you are evaluating it separately for each element of cc.

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.

Have a nice (and hopefully Fortran-free) weekend

Klaus

Reply to your second remark. Please note that this is a demo program only.

Klaus

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.

Klaus

This failure is no longer evident in v8.30 of FTN95.