soccer jersey forums.silverfrost.com :: View topic - FTN95 reports negative argument count for subprogram
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FTN95 reports negative argument count for subprogram

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Nov 11, 2022 2:52 am    Post subject: FTN95 reports negative argument count for subprogram Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8018
Location: Salford, UK

PostPosted: Fri Nov 11, 2022 8:46 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2586
Location: Sydney

PostPosted: Fri Nov 11, 2022 11:09 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Nov 11, 2022 12:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2586
Location: Sydney

PostPosted: Sat Nov 12, 2022 3:49 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Sat Nov 12, 2022 5:25 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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