Re: call tree
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Tue, 15 Jun 2010 19:42:35 +0000 (UTC)
Dick Hendrickson <dick.hendrickson@xxxxxxx> wrote:
I think it's impossible to do any kind of static source code tree
generation for any large program written in modern Fortran .
There are many large old Fortran programs that one might want
to work on. (Maybe only make small changes, though.)
When you first start working with a large program, nothing
looks familiar. A printed tree (or graph) is helpful as you
get to know the program. Many old large programs have a fairly
small tree, if the subroutines are large. Also, with the
Fortran 66 limit of six characters for names, they are often less
descriptive than you would like.
The only hope is to trap the subroutine entry code and build
a dynamic tree. My 4 reasons for saying this are:
1) With polymorphic variables and type bound procedures the
name of a called routine isn't available until run-time.
Probably still rare, but maybe not for long.
2) The rules for generic routine resolution are so intricate
that nobody will be able to write a stand-alone thing to
untangle them. However, since they are compile time resolvable,
you could recover them from some sort of compiler symbolic
I would expect much of the generic routines to be leaf routines
(that don't call much else, though likely some system intrinsics).
3) FORTRAN has allowed routines to be passed in as arguments and
then invoked via the dummy argument name since at least F77.
The same source code "name" can refer to different routines at
I believe back to Fortran II, it is, at least, in Fortran 66.
Usually only used once, or at least a small number of times,
even in large programs. If you link to the call using the
name, then one knows where to look.
4) Fortran's procedure pointers are similar to 1) and 3).
- Prev by Date: Re: How to deal with "missing points" in arrays
- Next by Date: Re: reordering expressions with NaN
- Previous by thread: Re: call tree
- Next by thread: Re: call tree