NoList compiler directive

NoList compiler directive

I have some "older" code that has in a couple *.for files what appear to be a compiler directives 'NoList/List''.  Unfortunately, (1) I'm not sure why it was necessary to have this directive, and (2) I can't find any information on it in Fortran documentation.

Upon compilation attempt, this "artifact" produces 2005 link errors of the form [***] already defined in *.obj

I have tried to systematically remove the NoList/List pairs from the code but this did not ultimately help.

For the heck of it, in case anyone might be ambitious enough to examine the code, I've attached it in a ZIP file.

Any help is appreciated.

 

 

AttachmentSize
Downloadapplication/zip Fortran code files.zip155.94 KB
14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Those could be from Microsoft Fortran - we don't support directives of that form.

You have three kinds of errors in this code.

Include file MASTER.INC contains COMMON declarations and DATA initializations, but this is included in two source files. It's not allowed to initialize COMMON variables in more than one program unit, though some operating systems (not Windows) let you get away with it. The solution is to move the DATA statements to a separate BLOCK DATA subprogram that also includes the COMMON declarations.

Subroutine OSSRPG appears in two different source files.

Lastly, there are several calls to SCNGEN passing ' ' to a dummy argument declared as CHARACTER*8. This is not allowed - the actual argument has to be at least as large as the dummy argument.

Retired 12/31/2016

Thanks Steve.  Yes, I was aware that s.OSSRPG appeared as part of MP4Xfor.for and as well as the entire contents of OSSRPG.for.  This redundancy puzzled me and so, for the hell of it, I deleted the $NoList/$List pair from the former file and removed the latter file from the project.  This seemed to make some of the link errors go away (maybe only one) but the others persisted and, as I said, successively removing the $NoList/$List pairs was to no avail.

Actually, and only fwiw, I believe the code was originally compiled using Lahey.

If I understand your last point (which I hadn't run into before), I think you are saying that calls of the form:

CALL SCNGEN(SCANSF,SCFLAG,' ',SFGYR,SFGMO,SFGDY,SFGHR,1270,STRNG1)

should be revised as:

CALL SCNGEN(SCANSF,SCFLAG,'        ',SFGYR,SFGMO,SFGDY,SFGHR,1270,STRNG1)

 

Thanks Steve.  Yes, I was aware that s.OSSRPG appeared as part of MP4Xfor.for and as well as the entire contents of OSSRPG.for.  This redundancy puzzled me and so, for the hell of it, I deleted the $NoList/$List pair from the former file and removed the latter file from the project.  This seemed to make some of the link errors go away (maybe only one) but the others persisted and, as I said, successively removing the $NoList/$List pairs was to no avail.

Actually, and only fwiw, I believe the code was originally compiled using Lahey.

If I understand your last point (which I hadn't run into before), I think you are saying that calls of the form:

CALL SCNGEN(SCANSF,SCFLAG,' ',SFGYR,SFGMO,SFGDY,SFGHR,1270,STRNG1)

should be revised as:

CALL SCNGEN(SCANSF,SCFLAG,'        ',SFGYR,SFGMO,SFGDY,SFGHR,1270,STRNG1)

 

You have to remove both $LIST and $NOLIST directives.

The bulk of the errors are due to the second problem I mentioned, where you include both COMMON and DATA statements for those commons in more than one source. That's not allowed. Move the DATA statements to a BLOCK DATA subprogram and leave just the COMMON and variable declarations in the incliude file. (The BLOCK DATA also has to include these.)

Yes, that fix for the argument error is fine

Retired 12/31/2016

I'm trying to understand the solution.  On the one hand, you say to:

Move the DATA statements to a BLOCK DATA subprogram and leave just the COMMON and variable declarations in the incliude file.

On the other hand, you say:

The BLOCK DATA also has to include these.

Not sure what you mean by "include".  Moving the data statement to a new Block Data unit seems straight forward.  If you are also saying to copy all the COMMON blocks (and presumably their associated declarations), then will have essentially duplicated Master.inc, no?.

BTW, inside both Stage1n2.for and Stage3.for there is a tiny Data Block that consists of only a couple variable declarations.  I presume if I'm successful, I can just expand these 2 existing blocks w/ the other stuff.

MASTER.INC has variable declarations, COMMON statements and DATA statements. When this is included in multiple files, there are multiple copies of the DATA statements, which is bad.

So, create a new source file MASTER_DATA.F as follows:

      BLOCK DATA MASTER_DATA
      INCLUDE 'MASTER.INC'
      ! move all the DATA statements from MASTER.INC here
      END

And by "move" I mean remove them from MASTER.INC and add them to MASTER_DATA.F. Add MASTER_DATA.F to the project.

DATA statements for local variables in subroutines are not a problem. You can do what you want with those.

Retired 12/31/2016

If I remember correctly, Lahey F77 for Windows had all variables SAVEd, so you wouldn't run into the ambiguity about SAVEing DATA in F77.
 

I appreciate your further clarification, Steve.  I think I have much clearer plan of attack.  Thanks for holding my hand on this mess.

It's interesting that in the now-obsolete Block Data piece, it gets accessed only by virtue of its being added to the compilation project (i.e., doesn't have to be explicitly referenced in the main program, e.g., (forgive me): use Block Data Master_Data.  Rather, since I've read that one of the first things the compiler looks for is a Block Data unit, I think the compiler basically says to the entire code:  "I've found and integrated the memory in this Block Data unit.  Whatever program units you are, if you need the information, feel free to use it."  Something like that is my impression.

In any case, this should be a topic for one of your Dr. Fortran sermons - another reason to migrate away from F77. <smile>

If I (hopefully) have success, I'll post back.

 

BLOCK DATA is not obsolete.

SAVE is not an issue here. Any DATA-initialized variable is implicitly SAVE. The problem is multiple DATA initializations of the same variable. The Microsoft linker does not permit this.

Retired 12/31/2016

I pretty much managed to resolve this issue - I'll spare details.  The good suggestions in this thread were instrumental.

However, along the way, I stumbled onto another issue that may serve as a free-standing post (or maybe it's already out there somewhere).  This has to do with the INCLUDE command for include files.  In my system, I have a dozen include files, but INCLUDE commands associated with them are scattered sporadically through the code.  Note that all the *.for and *.inc files are stored in the same project directory.

On the one hand, one might logically think that the only way for the code to "acknowledge" and use the include file contents is to place INCLUDE commands at the top of units that use them.

On the other hand, I think I empirically discovered that this in not necessarily the case.  I think I did an experiment in which I "hid" an include file from the code and noted a subroutine that did not reference it w/ an INCLUDE command.  If I remember right, the compiler really complained and pointed to a line in that subroutine involving a variable that couldn't be resolved without the include file.  (So I don't seem like a complete idiot, I'm going on my memory here - I could be wrong.)

Can anyone please set me straight on this?  If include files are in the project environment, must they be referenced with an INCLUDE command to be invoked?

The Fortran language standard defines (in 3.4 of the ISO/IEC 2010 document) the rules governing the INCLUDE statement. The notions of projects, IDE, makefiles, etc., are something else, not covered in the standard. My suggestion is to forget about projects, IDEs and build systems when pondering what included files should contain.

What the included file should contain depends on where the corresponding INCLUDE line is situated in the source code fed to the compiler.

Sometimes an include file contains modules and interface declarations, Such an include file is properly associated with an INCLUDE statement that is not within any program unit (Program, Subroutine, Function, Module,...).

Another use for an include file is to put in it PARAMETER and COMMON block declarations that are to be used in more than one subprogram by using multiple instances of the INCLUDE statement. These INCLUDE statements must be located inside subprograms, because the included declarations are not valid outside a program unit.

One way to decide where to put INCLUDE statements is to remember that the preprocessor output must be valid Fortran source code. In fact, compilers provide a switch to let you save the preprocessor output to a file if you so desire.

 

Include files in a project are just there for your convenience - the compiler has no idea they are there unless referenced in an INCLUDE statement. By default, the compiler will first look for include files in the same folder as the source that has the INCLUDE line, then it will follow the INCLUDE path (as potentially modified by project properties.)

Retired 12/31/2016

Steve,

Your comment:

the compiler has no idea they are there unless referenced in an INCLUDE statement

was just what I was looking for.  And I may have known this long ago but just forgot.  With this in mind, the "experiment" I alluded to may been a fig newton of my imagination.  I'll go with the explicit reference to include file with a properly-placed INCLUDE statement.

I appreciate you thoughts, too, mecej4.  Of your 5 blocks, I think the 4th one is most applicable to my situation.  I was less concerned as to where to place the INCLUDE statement but more as to whether it was necessary to always explicitly reference the include file using the INCLUDE statement.   Steve confirmed that it is.

I think I'm in good shape for now and always appreciate the helpful comments on this forum

Leave a Comment

Please sign in to add a comment. Not a member? Join today