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:

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:

ftn95 /64 /check bug.f90 /inhibit_check 6 /link

Running the program produces the following error:

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.

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.

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

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

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.

Could be a problem with the stack being corrupted ?

Indeed, yes. As I reported earlier (https://forums.silverfrost.com/Forum/Topic/4215), 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.

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.

Quoted from mecej4 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 ?

Quoted from JohnCampbell

Quoted from mecej4 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?