@jdietz224 ,
TL;DR: almost anything with array arguments in subprograms and the typical problems encountered in Fortran programs requiring trouble-shooting are good cases for graphical debugging tools.
Please note in the present day and age if there are computational scientists/engineers/technicians hesitating to use graphical debugging facilities of integrated development environments (IDEs), it can be indicative of a significantly hesitant or a certain minimalist attitude toward adoption of certain good coding practices that have long (1970s and earlier) been recognized as leading to safe, productive, and efficient computations e.g., by Kernighan and Plauger in 1978.
Now, in the context of Fortran, a simple aspect to note where the issues pop up is with the supposed strength of Fortran i.e., arrays.where the importance of paying to the right attributes to choose with subprogram arguments and also explicit interfaces which tend to be overlooked and you will be surprised by the overlap of those who prefer to employ the debug-only-with-print approach and the practice to go with implicit interfaces.
So with this background, here’s a simple illustration:
- consider an external procedure in file
s1.f where the assumed-shape attribute was chosen for the received argument: note the PRINT statement
subroutine s1( x )
integer, intent(in) :: x(:)
print *, x
end subroutine
- consider another external procedure in
s2.f that attempts to consume `s`` with an implicit interface
subroutine s2( y )
integer :: y(*)
call s1( y )
end subroutine
- and a main program that invokes
s2
integer :: n(3)
n = [ 1, 2, 3 ]
call s2( n )
end
- Try it with a Fortran processor and you will notice the
PRINT statement does NOTHING:
C:\temp>gfortran -c -ffree-form s1.f
C:\temp>gfortran -c -ffree-form s2.f
C:\temp>gfortran -c -ffree-form p.f
C:\temp>gfortran p.o s1.o s2.o -o p.exe
C:\temp>p.exe
C:\temp>
You can extrapolate from this trivial case to a large code base where across various libraries and remote calls, the instruction arrives at something like s2 where the inadequateness of argument passing lead to PRINT being useless, the variable reference itself is garbage.
Whereas a basic familiarity with studying objects in memory and dereferencing their addresses, etc in a debugger would allow one to debug such a situation easily.
But now, note the above illustration is not conformant, but you may or may not be surprised by the large amount of Fortran codebases out there which do not conform and where their maintainers attempt support and development using PRINT statements!
