FPP Feature Request

[jimdempseyatthecove]

At times it can be handy to use FPP to aid in diagnosing a problem with your code. Code that you wold normally compile without FPP.

For example changing a subroutine name, or adding diagnostics into the program in a manner that has no effect when compiled without FPP.

A few suggestions:

Add option:

       /macros=<file>        A file to pre-pend to the Fortran source which can hold the #defines you desire.

Add to the compiler an FPP directive

      !fpp$    <anything here to be parsed by FPP .OR. Fortran>
      !fpp$   #include "AdditionalFileForFPPtoInclude.h"

I find it necessary to have several #define and/or conditional #if statements. It is too cumbersome (not practical) to use command line options to meet the needs. Having a means to specify a fpp header file would solve this issue.

Note, the pre-pend macro file alone may be sufficient to accomplish the diagnostic purpose, thus leaving the source code untouched.

subroutine foo(a, b, c)
  !fpp$ use MyDiagnostic ! only when using FPP
  ...
  cOnTiNuE ! normally noop, or CALL MyDiagnostic_Here(__FILE__, __LINE__) when FPP'd
  ...
  CALL MPI_SEND(....) ! when FPP'd, CALL MyDiagnostic_MPI_SEND(__FILE__, __LINE__, ....)

In the above example, the !fpp$ use MyDiagnostic would seldom be required.

Also note, the following would be permitted:

!fpp$!dir$ ...

IOW the use of the !dir$ is conditionalized with the use of fpp.

Jim Dempsey

[andrew_4619]

The IF and IF DEFINED directives specify a conditional compilation construct. IF tests whether a logical expression is .TRUE. or .FALSE.. IF DEFINED tests whether a symbol has been defined. [See Note]

The directive-initiated construct takes the following form:

cDEC$ IF (expr)    [or cDEC$ IF DEFINED (name)]
      block
[cDEC$ ELSE IF (expr)
      block]...
[cDEC$ ELSE
      block]
cDEC$ ENDIF

[jimdempseyatthecove]

Andrew,

You are missing the point. I am not talking about conditionalizing blocks of code.

I am suggesting a means to instrument your code without inserting Intel compiler directives. In some cases, the software engineer is placed in a situation whereby they are required not to edit "certified" source files.

If only /macros=<file> is used/implemented, then you do not need to decorate the program.

As an example, assume you are required to use a procedure developed in the 1960's .AND. required not to make any changes to the source code. You are also required to use "modern Fortran" for the application. The "modern Fortran" code is using User Defined Types as opposed to COMMONs but this require immutable source file is using COMMONs

By using FPP this can be easily attained:

! New region information
#define TLENR ThreadContext%pFSInput%rTLENR
#define YOUNG ThreadContext%pFSInput%rYOUNG
#define YOUNGF ThreadContext%pFSInput%rYOUNG
#define BETA ThreadContext%pFSInput%rBETA
#define BETAF ThreadContext%pFSInput%rBETA
#define RHOB ThreadContext%pFSInput%rRHOb
#define RHOF ThreadContext%pFSInput%rRHOb
#define RHOE ThreadContext%pFSInput%rRHOe
#define DIELB ThreadContext%pFSInput%rDiaElasb
#define DIAEFF ThreadContext%pFSInput%rDiaElasb
#define DIELE ThreadContext%pFSInput%rDiaElase
#define DIAROB ThreadContext%pFSInput%rDiaAerob
#define DIAROF ThreadContext%pFSInput%rDiaAerob
#define DIAROE ThreadContext%pFSInput%rDiaAeroe

The use of FPP is particularly handy when revising code during modernization. You can make the changes... while keeping available using a difference program to locate algorithmic changes you make (as opposed to placement changes).

Note, while the source file could be edited to contain:

#include "youMacros.h"

The source file then is required to be compiled with FPP (which may not be available using a different vendor's compiler).

Jim Dempsey

[Steve_Lionel]

First, as I am sure Jim and Andrew know, the cDEC$ IF, etc. constructs are not understood by FPP (the preprocessor) but by the compiler itself. FPP knows #if, #ifdef, etc.

For Jim's request, I would think that the use of a suitable define, specified on the command line with /D combined with #ifdef, would suffice. This is, after all, how most of the world does this sort of thing.

[jimdempseyatthecove]

Steve,

The simple /D... on the command line is sufficient for but a few defines. It would be impracticable for 10's or 100's defines.

Jim Dempsey

[Steve_Lionel]

You can always #include a file with more #defines.

[IanH]

The command line options defining the defines could be placed in a response file.

There are many existing text processing tools out there that could be used to do simple source transforms such as these.  Given it is rather esoteric, I'm not sure what benefit there is from having this sort of thing built into a compiler driver.

(Changing the meaning of source code through the preprocessor seems inconsistent to me with that source code being "immutable".)

[jimdempseyatthecove]

>>(Changing the meaning of source code through the preprocessor seems inconsistent to me with that source code being "immutable".)

Sometimes a compiler provided intrinsic function will not yield the desired result. .OR.
you are trying to track down an exception case, say for example, where an/some intrinsic function produces an unusual result. And this may occur throughout the application. And you would rather not edit the sources with !dir$ if(...) !dir$ else ... !dir$ endif

Jim Dempsey

[mecej4]

Jim, have you considered gpp ? To me, it appears to meet most of the needs that you expressed. In particular, it has a command line option --include, with which you could name a file containing macro definitions (or anything else that you want processed first), and is not tied to any particular programming language.

[andrew_4619]

Jim,You  can do what you asked with embedded compiler directives. I personally don't see much difference in embedding non standard  compiler directives or non standard fpp directives. And it seems a strange argument to say that with fpp you are not modifying the code. Anyway nothing more to add.

[mecej4]

Sorry, Jim, I also fail to understand how you can employ a preprocessor that changes the sacred old source file to new input source that the compiler is then made to process, and claim that the old code is not disturbed. Regardless of how you implement preprocessing steps, with macros in include files, command line options or option files, it is inescapable that the syntax and semantics of the input to the compiler is different and the OBJ file that it produces will probably be different from the OBJ file that it would produce from the ancient source file.

In fact, a version control system can be used or backup copies of the old source file can be kept as read-only files. Or, you could put together a macro processing system that, controlled with suitable options and applied twice, will give you back the original input file. These capabilities could be sources of comfort, but I don't see how an "untouched" claim could be made.

[jimdempseyatthecove]

>>These capabilities could be sources of comfort, but I don't see how an "untouched" claim could be made

The objective I wish to accomplish is

1) No modification to source files
2) No reliance on FPP (and consequently no #include, #...), files can be compiled without FPP, and without Intel compiler directives
3) Means to provide the name of an FPP #include file to be loaded prior to parsing the Fortran source with FPP
    (IOW a completely non-intrusive means of augmenting the compilation using Intel's FPP)

Note, while one can mung this together using make, this would be convoluted and this may break the dependencies (make creating temporary concatenated file which is then compiled), it would be much simpler to do this via the IDE by way of ifort command line option.

The problems with using a response file to /Dmacro=replacement are: a) You cannot specify an #include file, b) you cannot specify a multi-line expansion.

Jim Dempsey

[JohnNichols]

I must say with sadness that what you just wrote made no sense to me at all -- I just do not know enough about this stuff.  So I thought if I translated it in Scottish Gaelic it might make more sense 

The answer is sadly no. 

I am glad you guys know what you are doing 

Gubrath 

JMN

Is e an amas a tha mi airson a choileanadh

1) Gun atharrachadh air faidhlichean stòr
2) Gun a bhith an urra ri FPP (agus mar thoradh air sin chan eil #include, # ...), faodar faidhlichean a chuir ri chèile às aonais FPP, agus às aonais stiùiridhean cruinneachaidh Intel
3) A ’ciallachadh ainm faidhle FPP #include a thoirt seachad airson a luchdachadh mus parsar stòr Fortran le FPP
    (IOW dòigh gu tur neo-inntinneach airson cur ris a ’chruinneachadh le bhith a’ cleachdadh FPP Intel)

Thoir fa-near, ged as urrainn dha seo a thionndadh còmhla le bhith a ’dèanamh make, bhiodh seo air a chronachadh agus dh’ fhaodadh seo na h-eisimeileachd a bhriseadh (dèan faidhle co-chruinnichte sealach a tha an uairsin air a chur ri chèile), bhiodh e fada nas sìmplidh seo a dhèanamh tron ​​IDE tro loidhne-àithne ifort roghainn.

Is iad na duilgheadasan le bhith a ’cleachdadh faidhle freagairt gu / Dmacro = ath-chur: a) Chan urrainn dhut faidhle #include a shònrachadh, b) chan urrainn dhut leudachadh ioma-loidhne a shònrachadh.

Jim Dempsey