Here are some of the tools and "tricks of the trade" that I use to maintain LAPACK.
LAPACK is backward compatible. If you need to change the calling sequence to an existing routine, or its amount of workspace, then you MUST create a new routine. You cannot make any change that would break a user's existing code calling LAPACK.
The most useful options to ftnchek are:
ftnchek -declare -noextern -portability -library *.f > ~/listing
For example, if I want to check the s.p.complex and d.p.complex EIG codes (source and testers), I would type:
alias ftnchek 'ftnchek -declare -noextern -portability -library'
cd LAPACK/TESTING/EIG
ftnchek c*.f z*.f ../../SRC/c*.f ../../SRC/z*.f ~/eig.listing
and then view the listing file for errors...
Be aware that d.p.complex is not part of the ANSI standard, so it won't recognize a lot of the COMPLEX*16 stuff, and will thus give a lot of extraneous error messages.
These tools polish the new codes so that they conform to to the LAPACK style. I use the same for LAPACK.
SGI IRIX64
f77 -g -DEBUG:subscript_check=ON -trapuv *.f
ALPHA Tru64
f77 -C=all *.f
AIX
xlf -C *.f
Solaris
f77 -C *.f
Refer to the release_notes.html file for "machine specific installation hints".
If the code passes these tests, then we say that it can be included in LAPACK.