|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Fri Dec 01, 2017 4:13 pm Post subject: 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???
[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
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)
|
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Fri Dec 01, 2017 4:32 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Fri Dec 01, 2017 6:14 pm Post subject: |
|
|
Quote: | 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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Dec 02, 2017 7:13 am Post subject: |
|
|
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 |
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Sat Dec 02, 2017 11:22 am Post subject: |
|
|
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:
Code: |
! ==============================================================================
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Dec 02, 2017 12:50 pm Post subject: |
|
|
The quick fix is write
Code: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Dec 02, 2017 1:15 pm Post subject: |
|
|
Klaus
Another thing that I notice during a quick glance through your code...
The line
Code: | 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. |
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Sat Dec 02, 2017 1:28 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Sat Dec 02, 2017 1:34 pm Post subject: |
|
|
Reply to your second remark. Please note that this is a demo program only. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Dec 02, 2017 4:40 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Mon Apr 23, 2018 12:29 pm Post subject: |
|
|
Klaus
This failure is no longer evident in v8.30 of FTN95. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|