Re: Bounds Check Overhead

["Nasser Abbasi" <nma@12000.org>]

Hello

"Richard Maine" <nospam@see.signature> wrote in message 
news:1hfxy4r.1sv2j76l6cgg1N%nospam@see.signature...
> Nasser Abbasi <nma@12000.org> wrote:
>

> Internal procedures are not compiled separately. Therefore, the odds of
> catching things like this in an internal procedure are far better. It
> still is not guaranteed. I might have seen some bugs resulting form
> uncaught errors in that situation. But the odds are at least better.
>

Ok, you are correct, the Fortran example was using an external proc (even 
though it was in the same source file) while the Ada one used an internal 
proc.

Here is a Fortran one that is using internal procedure that attempts to 
change the loop counter, so that now we have the same type of code. In Ada 
we call an internal proc to try to update a loop counter, and in Fortran we 
call an internal proc to try to update a loop counter. I hope this you'll 
find it to be a better test.

$ cat a.f90
----------------------
PROGRAM MAIN

     DO I=1,10
        CALL foo(I)
        PRINT *,I
     END DO

CONTAINS

   SUBROUTINE foo(I)
     I=I+1
   END SUBROUTINE

END PROGRAM MAIN
------------------

$ g95 a.f90
$ ./a.exe
 2
 4
 6
 8
 10
 12
 14
 16
 18
 20

Please note that I did not use the intent(in ) in the Fortran internal 
proc(), this is by purpose. I wanted to see if the compiler will detect that 
a call is being made to a proc which is taking a loop counter as an 
argument, where it does not have intent(in) on that argument declared.

I do not think this is too hard for the compiler to check, but I can be 
wrong. I would have to assume then that this is a g95 issue where it just 
does not do this extra check if it is supposed to be part of the Fortran 
standard to try to check against loop counters updates.

thanks,
Nasser