Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
14 Views

Preprocessor directives not carrying through to INCLUDE files

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
Highlighted
Valued Contributor I
14 Views

This could be related to the

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

0 Kudos
Highlighted
Beginner
14 Views

Yes, I tried making it CMKL.F

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
Valued Contributor I
14 Views

This cannot be correct.

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
Highlighted
Beginner
14 Views

Perhaps my wording in the #3

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
Highlighted
Retired Employee
14 Views

This won't work. The

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

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
14 Views

#include "file" occurs at

#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