|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Sun Dec 05, 2021 3:08 pm Post subject: 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.
Code: | ! 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.
Code: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Dec 06, 2021 9:35 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Mon Dec 06, 2021 11:15 am Post subject: |
|
|
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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Dec 06, 2021 12:43 pm Post subject: |
|
|
mecej4
No. You are probably right. The compiler may not need to know the INTENT at the point of call. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Mon Dec 06, 2021 2:06 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Dec 06, 2021 4:46 pm Post subject: |
|
|
Yes thanks. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Dec 14, 2021 4:05 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Tue Dec 14, 2021 4:26 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Dec 14, 2021 6:43 pm Post subject: |
|
|
mecej4
I may have a fix after all. Will get back to you shortly. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Dec 15, 2021 12:36 pm Post subject: |
|
|
This failure has now been fixed for the next release 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
|