I always learn something here (global error checking)

Just to give kudos, one of the posts I recently read (not sure which one, sorry) spoke of using INCLUDE's for joining up all the routine to be compiled versus separate lines for each compile-able file. I was worried that perhaps I had too much code to compile at once.

Previously, I had used the INTERFACE to type check arguments. But, you can't have an INTERFACE inside of the routine you are checking (i.e. no INTERFACE for SUBROUTINE ABCD can be seen inside ABCD). So I was doomed to manually look at each file/module to see if there were interface problems. I already used CHECKMATE to assist with argument checking, but finding each instance was very time consuming.

So, using the idea of a single compile, I put together all of the routines that make up each program and did a big compile (with /NO_CODE option to prevent an object file). Applying this same process to the 9 major MAIN programs in the suite I'm developing, this uncovered [u:a6a43fab6d]every[/u:a6a43fab6d] inconsistency.

Having already spent two days using the manual method with limited success, I finished the task in under 6 hours. No more argument problems anywhere, regardless of /DEFINT_KIND settings.

So, thanks to all of you who contribute and think outside of the box. It has helped me immensely! Bill

Bill,

It is good to hear you did get this approach to work, especially as well as you report. What were the compile options you used ?

I have tried this approach but did not appear to have the success you have found; of finding ALL argument errors. Could there be a problem with the order of the definition and then use of the routines ?

The idea of listing all files to load, then using this as a list of source files in include statements should provide for some call argument consistency checking. I have done this fairly successfully, also producing the .obj file for use with slink / slink64. It does get a bit more difficult with libraries and locating their include files for COMMON definitions.

It is a good static check to include.

It would have been good if the Fortran rules regarding INTERFACE were a bit more relaxed, so that an include/module file of INTERFACE definitions for all routines in a project could be included in each routine and then used to check all routine calls and their definition. This would be a great static check at compile time, although I don't know what overhead would be involved. ( Perhaps USE Global_Interface_Module would work better ) I like the idea of this USE Global_Interface_Module being in the actual routine, to check the consistency of the routine against the global interface file referenced in every routine, rather than being a Fortran error. It would be a way of checking the duplication of routine definition and INTERFACE definition, that is a flaw with the Fortran INTERFACE rules. I do use it for some libraries, but not regularly.

John

John,

Thanks for the reply. Yes, I was surprised that it worked as well as it did. The INTERFACE stuff was the hardest to overcome.

To get the best results, you'd need to specify the includes from lowest to highest level. That said, the first attempt was in the opposite direction which caused compile issues (resources). So, I put the common routines first but without regard for lowest level to higher level ordering, then the program specific routines next, then the MAIN for that program unit.

My compile line looks like this. All the arguments are chosen deliberately for my application. It is in a CMD file, so there are the % arguments:

/132 /NO_CODE /NO_QUIT  /persist /ERROR_NUMBERS /DEFINT_KIND %2 /SAVE /ZEROISE /FPP /CFPP /WINDOWS  /wide_source %implicit_option% /include .\logplot /include .\plotsoft 

The %implicit_option% reflects whether or not I use /IMPLICIT_NONE or not. Some of the old code doesn't have all the variables defined (yeah, I know, bad form; but I inherited this code!).

My code for the file I compile looks like this :

	include 'c-masterCFUNC_Functions.for'
	INCLUDE 'CBLOCK.FOR'
	INCLUDE 'CBLOCK_BLOCK_DATA.FOR'
	include 'catalog_repair.for'

The first line is actually another INCLUDE file of the 200+ support routines.

All I can say about finding all the problems is: It appears to work!