Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Preprocessor directives not carrying through to INCLUDE files

ereisch
New Contributor II
843 Views

I'm trying to implement code that takes two different paths, depending on whether a compile-time macro is set.  My source file (shortened for clarity):

    SUBROUTINE FFTCT(Z, N)

#ifdef WITH_MKL
    USE MKL_DFTI
#endif

    IMPLICIT NONE
    INCLUDE 'CMKL.TEXT'

    COMPLEX*8   Z(N)
    INTEGER*4    N
{...}

#ifdef WITH_MKL
    {MKL-specific section}
    RETURN
#endif

{non-MKL section}
    END

And CMKL.TEXT:

    LOGICAL*1  USE_MKL

#ifdef WITH_MKL
    type(DFTI_DESCRIPTOR), POINTER :: FFT_HANDLE
    type(DFTI_DESCRIPTOR), POINTER :: IFFT_HANDLE
#endif

    COMMON/FFT_CFG/ USE_MKL

#ifdef USE_MKL
  &  , FFT_HANDLE,
  &    IFFT_HANDLE
#endif

When I try to compile a module for this routine with "ifort -module ./mods/ -warn noalignments -DWITH_MKL -extend-source 132 -assume nounderscore -gen-interfaces nosource -syntax-only fftct.fpp", everything goes fine.  However, if you remove the WITH_MKL definition from the command line, you receive errors about the DFTI_DESCRIPTOR type not being declared.  If I instead don't put those variables in the INCLUDE file, and instead place them directly in the compilation unit, the module file is generated without issue in both cases.  So it appears as though the preprocessor directives are not being carried into included files, and are only being applied at the top-level file.  Is this expected behavior?

Using ifort 18.0.5.

0 Kudos
6 Replies
Juergen_R_R
Valued Contributor I
843 Views

This could be related to the ending .text. Did you try a .F ending or .F99 ending? 

0 Kudos
ereisch
New Contributor II
843 Views

Yes, I tried making it CMKL.F and it still produces the same results.  But I would expect that if you're passing the -fpp option (which I've tried doing as well, though didn't mention in the original post) it should run the preprocessor on all source files that are being compiled, including any chain-included files.

It should be noted that there's also a warning about "Bad # preprocessor line" when you compile these files, all in CMKL.F (or CMKL.TEXT).  However, since (with the WITH_MKL macro set) it compiles just fine, that seems to be further proof that the preprocessor isn't running properly on all chain-INCLUDE'd files at one of the stages of compilation.

0 Kudos
Juergen_R_R
Valued Contributor I
843 Views

This cannot be correct. Before parsing the first file which includes the second file, the compiler/preprocessor cannot know that there is another source file. You have to explicitly tell it.

0 Kudos
ereisch
New Contributor II
843 Views

Perhaps my wording in the #3 was poorly chosen.....by "it should run the preprocessor on all source files that are being compiled", I meant all source files that are part of the compilation unit being compiled.  In other words, if test.fpp has a line "INCLUDE 'TEST1.TEXT'", the preprocessor should be run on both test.fpp and TEST1.TEXT (though it, in theory, should pull in the contents of TEST1.TEXT into the source "stream" of test.fpp rather than parsing it separately, since TEST1.TEXT could depend on directives specified in its parent).

0 Kudos
Steve_Lionel
Honored Contributor III
843 Views

This won't work. The preprocessor treats the INCLUDE line as just a line of source. By the time the compiler sees the INCLUDE, the preprocessor is no longer in play.

Solution 1: Use #include

Solution 2: In the include file, use !DEC$ IF DEFINED(WITH_MKL) ... !DEC$ ENDIF

0 Kudos
jimdempseyatthecove
Honored Contributor III
843 Views

#include "file" occurs at preprocessor time. Whereas
include "file" occurs after preprocessing

>> errors about the DFTI_DESCRIPTOR type not being declared

I suspect that the source file (not shown) containing the TYPE declaration of DFTI_DESCRIPTOR (iow lack thereof) may be the cause of the issue.

Had this occurred after FPP in the INCLUDE CMKL.TEXT you would have received something to the effect of invalid FPP directive (#if... occurring outside of the FPP preprocessing).

** Because CMKL.TEXT contains FPP directives, use #include as Steve suggests.
IOW you have two problems with your program.

Jim Dempsey

0 Kudos
Reply