False report of subscript out of bounds

The following test program is intended for the sole purpose of demonstrating a bug in the current compiler when /check is used. The full program where the bug was encountered had dozens of subprograms and was about 7,200 lines long.

! compile with /check
program gamdrv
!   implicit none     ! activating this declaration makes bug go away
   integer, parameter :: MD = 8
   integer neqn, ipar(MD+1)
   real h, y(MD)
   integer iout       ! unused, but its presence causes bug
   external solout
   neqn=8
   y(1:8) = (/1.0,0.,0.,0.,0.,0.,0.,0.006/)
   h = 0.01
   ipar(1:9)=(/8,1,2,3,4,5,6,7,8/)
   call gamd(neqn,y,h,solout,ipar)
end program gamdrv
!
subroutine gamd(r,y0,h,solout,ipar)
   implicit none
   integer, intent(in) :: r, ipar(*)
   real, intent(in out) :: y0(r), h
   integer :: irtrn
   external :: solout
   call solout(ipar, irtrn)
   return
end subroutine gamd

subroutine solout(ipar,irtrn)
   implicit none
   integer ipar(*),irtrn,nindsol
   integer i
   nindsol = ipar(1)
   print '(1x,20i4)',(ipar(i),i=2,nindsol+1)
   irtrn = 0
   stop
   return
end subroutine solout

Note that there are some variables present that are not really needed, but their presence is necessary for the bug to occur.

The bug is exhibited (subscript out of bounds on the PRINT statement) with compiler versions 8.82 and 8.61, with or without /64, provided /check is used. The old 7.20 version does not have this bug.

Array subscript(s) out-of-bounds at address 401f3c

Within file salbug.EXE
in SOLOUT in line 31, at address 21a
in GAMD in line 22, at address 2f2
in GAMDRV in line 13, at address 128

Thanks.

mecej4

Thanks for the bug report which I have logged for investigation.

In the main program, the subroutine gamd requires an interface but correcting this does not prevent the false error report.

The declaration of the array ipar as being INTENT(IN) with assumed size is an unusual mix of 77/90 and the failure does not occur when this is changed to assumed shape.

Thanks, Paul.

I am puzzled as to why you say that GAMD requires an explicit interface. I looked at the list of features of procedures that cause an explicit interface to be necessary, and I felt that for GAMD an implicit interface was good enough.

Specifically, INTENT specifications are the responsibility of the programmer, and their presence does not make an explicit interface necessary. Am I missing other points?

mecej4

No. You are probably right. The compiler may not need to know the INTENT at the point of call.

Paul, I removed the INTENT declarations from the program that I posted above. After repeating the runs (with /check and /64 /check), I did not see any effect on the bug.

Yes thanks.

mecej4

An initial investigation for this bug has been carried out.

The runtime faillure occurs at the array bounds check on ipar within solout and solout is called from gamd where solout is an argument.

Clearly bounds checking for assumed size arrays is not working consistently in this context and this is not surprising. The problem is how to switch the checking off in this context.

The checking takes place within solout and in that context there is currently no way of knowing that solout was an argument at the point of call.

So at the moment this issue remains unresolved.

Thanks.

A workaround that I may use is to put the problematic subroutine (SOLOUT) all by itself into a new source file, and compiling the new file without /check.

mecej4

I may have a fix after all. Will get back to you shortly.

This failure has now been fixed for the next release of FTN95.