forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

I always learn something here (global error checking)

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sat Jan 28, 2017 12:47 am    Post subject: I always learn something here (global error checking) Reply with quote

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 every 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
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Jan 28, 2017 2:14 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sat Jan 28, 2017 6:12 am    Post subject: Reply with quote

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:
Code:

/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 :
Code:

   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!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group