- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have found a bug in a large program where a subroutine was written as:
program main implicit none real, dimension(6) :: x call f(x, 7) write (*,*) x contains subroutine f(x, n) integer :: n real, dimension(n) :: x integer :: i do i = 1, n x(i) = 0.0 end do end subroutine f end program main
This program runs fine with ifort and bounds checking even though the code is obviously buggy. Is there an option to catch those kind of bugs? Obviously, I need an option that checks this kind of bugs at run-time where the dimension of the arrays is not statically known as here.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem arises that you are neither using assumed shape arrays nor explicitly shaped arrays, but an array whose dimension depends on another argument of the subroutine to be called. This cannot be checked at compile time. If it throws an error at runtime is an implementation detail / quality feature of the compiler. ifort and gfortran don't detect it (but the Fortran standard also doesn't demand it to be detected), NAG does detect it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you want array bounds checking on the above program (with contained subroutine), use
real, dimension(:) :: x
This will permit the contained routine to be called with the caller's array descriptor (or descriptor of array temporary). Thus the bounds checker can ascertain the index out of bounds.
Note, the subroutine with dummy having (:) must have its interface known. IOW be in a contains section of module or procedure or have its interface declared.
Using real, dimension(:) :: x in subroutine f will permit you to call the subroutine with .LE. the size of array x.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Juergen
I know that this is a bad way to program nowadays, but I have to fix a very old code using such a style. I also know that the Fortran standard says that this type of bug is undefined behaviour.
But I am not a language lawyer. I am a programmer. And this kind of bug is very dangerous as it can corrupt the stack. Therefore, I believe that it should be nice to have an option to throw an error at runtime to catch these kind of bugs.
@Jim
I have 200 000 lines of code programmed in such a way. That's why it would be helpful to get a run-time check for such errors.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Use more than one compiler for such a case. As I said, the NAG compiler catches this runtime error when compiled with full checking flags.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Francois F.,
If your license conditions allow, you can try submitting a support incident at Intel OSC (https://supporttickets.intel.com/servicecenter?lang=en-US) to request the Intel Fortran team to enhance the Intel Fortran compiler option(s) with either -check or some such to cover your situation as well. You may have noted options such as -check:bounds, -check:shape, etc. can diagnose certain array shape mismatch and bounds violation issues but Intel Fortran presently doesn't appear to offer anything to catch the kind of error you show. You may influence them to extend their product further!
https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-check
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page