|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Fri Nov 11, 2022 2:52 am Post subject: FTN95 reports negative argument count for subprogram |
|
|
The test code below, when compiled with /64 /check /inhibit_check 6, aborts with a strange error report.
The program:
Code: | program negcountarg
implicit none
real, external :: dumach
real uround
uround = dumach()
print *,'Uround = ',uround
end program
real function dumach ()
implicit none
real :: u, comp
u = 1.0
u = u*0.5
call dumsum (1.0, u, comp)
do while(comp /= 1.0)
u = u*0.5
call dumsum (1.0, u, comp)
end do
dumach = u*2.0
return
end function dumach
subroutine dumsum(a, b, c)
implicit none
real, intent(in) :: a, b
real, intent(out) :: c
c = a + b
return
end subroutine dumsum |
Compile and link:
Code: | ftn95 /64 /check bug.f90 /inhibit_check 6 /link |
Running the program produces the following error:
Code: | Silverfrost 64-bit exception report on T:\ODEPACK\splt1\ncom\v90\tbed\BUG\bug.exe Thu Nov 10 19:50:53 2022
Attempt to call a routine with minus one arguments when three were required at address 1a0093e9
Within file bug.exe
in DUMSUM at address 145
in DUMACH in line 21, at address 119
in NEGCOUNTARG in line 6, at address 3d |
Obviously, something went wrong in counting the number of actual arguments for the compiler options used.
The bug does not occur for 32-bit runs, in my limited experience. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8018 Location: Salford, UK
|
Posted: Fri Nov 11, 2022 8:46 am Post subject: |
|
|
mecej4
Thank you for the feedback.
This code does not fail on my machine, with or without /inhibit_check.
For the moment I am assuming that an existing fix (not yet released) resolves this issue. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2586 Location: Sydney
|
Posted: Fri Nov 11, 2022 11:09 am Post subject: |
|
|
It is sensitive !
I can reproduce your result with ftn95 ver 8.92 then use sdbg64
Runs ok in Plato with Checkmate x64
I changed line 7 to the following and still failed
: print *,'Uround = ',uround, epsilon (1.0)
However I then included a count of calls to dumsum and the failure disappeared !
Could be a problem with the stack being corrupted ?
I am reluctant to use intent, especially with /check
Code: | program negcountarg
implicit none
real, external :: dumach
real uround
uround = dumach()
print *,'Uround = ',uround, epsilon (1.0)
end program
real function dumach ()
implicit none
real :: u, comp
integer :: ncall
ncall = 0
comp = 0
u = 1.0
do while(comp /= 1.0)
u = u*0.5
call dumsum (1.0, u, comp)
ncall = ncall+1
end do
write (*,*) 'ncall =',ncall
dumach = u*2.0
return
end function dumach
subroutine dumsum(a, b, c)
implicit none
real, intent(in) :: a, b
real, intent(out) :: c
c = a + b
return
end subroutine dumsum |
changing to /inhibit_check 5 with FTN95 Ver 8.92 (25-Oct-92) removes the error ?
ftn95 /64 /check bug.f90 /inhibit_check 5 /link |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Fri Nov 11, 2022 12:13 pm Post subject: |
|
|
John, thanks for running the additional tests.
It is understandable that using /inhibit_check 5 makes the bug go away, since Check-5 is the designation for checking argument sizes and types on function/subroutine entry. As I noted in a recent thread, the integer overflow occurs during address calculations based on array subscript ranges.
Inhibiting Check-5 probably bypasses those calculations, since the user explicitly requested that they should not be done!
There seems to be some linkage between Check-5 and Check-6, and that linkage has been changed recently with newer compiler versions. The details are not clear to me.
Quote: | Could be a problem with the stack being corrupted ? |
Indeed, yes. As I reported earlier (http://forums.silverfrost.com/viewtopic.php?t=4706), in the test program of that thread the dummy argument subscript range was taken from the stack, and happened to be 0x8080808080, i.e., undefined. Whether that was because the range value was being read from the wrong stack location, or the location never had a valid value entered into it, is a mystery.
Quote: | I am reluctant to use intent, especially with /check |
For my uses of FTN95, checking and fixing wrong INTENT is an important goal, so I hope that this bug will be fixed.
Last edited by mecej4 on Sat Nov 12, 2022 5:21 am; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2586 Location: Sydney
|
Posted: Sat Nov 12, 2022 3:49 am Post subject: Re: |
|
|
mecej4 wrote: | As I noted in a recent thread, the integer overflow occurs during address calculations based on array subscript ranges. |
I am puzzled by the error being related to array subscripts, when there are no arrays defined for any routine interface ? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Sat Nov 12, 2022 5:25 am Post subject: Re: |
|
|
JohnCampbell wrote: | mecej4 wrote: | As I noted in a recent thread, the integer overflow occurs during address calculations based on array subscript ranges. |
I am puzzled by the error being related to array subscripts, when there are no arrays defined for any routine interface ? |
Sorry for causing confusion. I have edited my statements above to clarify that the subscript checking errors were for the test program in my other post, "Spurious integer overflow: Short new reproducer". I am making a conjecture that similar stack related errors may occur with regard to the extra information that needs to be passed on the stack to enable argument types and counts to be checked. How else could one come up with a negative count for the arguments passed? |
|
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
|