Preprocessor bug (macro + underscore)

[a_d]

Hi,

ifort -V

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20091012 Package ID: l_cprof_p_11.1.059

Let test.for contains:

[fxfortran]      subroutine foo()
      implicit none
#define MACRO_0
      integer i_n, i
      do i = 0, i_n
MACRO_0
      end do
      end
[/fxfortran]

Now compile with

[bash]ifort -o test.o -c -fpp test.for[/bash]

and get

[bash]test.for(5): error #6404: This name does not have a type, and must have an explicit type.   [I_N0]
      do i = 0, i_n0
----------------^
compilation aborted for test.for (code 1)
[/bash]

It seems the preprocessor substitute only MACRO_ and what comes after the "_" is appended to the previous line.

A. Dechaume.

[jimdempseyatthecove]

This is related to your file being of type .for and thus being fixed format.
Try adding at least 6 spaces (not tab) to left of MACRO_0 on line 6

This corrects the macro expansion on my system

Note,

If you try to fix this by adding-fpp:-free to the command line

Then the only workable macros (in a fixed format file) will be those with non-blank characters in columns 1:6) IOW this will work with FORMAT statement etc

#define MACRO_0 123FORMAT(...
...

MACRO_0

Witout -fpp:-free then you can place the macro indented by 6 places

#define MACRO_0 epsilon = 1.0D

X=MACRO_0

The expansion of the macro will not include the lead-in whitespace therefore you have to insert the requiredwhitespace on fixed format sources (.for or .f) When using free format (.F90) statements can be flush to the left margin so the macros will be friendlier to use

Jim Dempsey

[a_d]

Hi,

unfortunately, modifiyng the source code is not an option.

Note that the gnu and pgi compilers can process this code correctly, and so far with the intel compiler we have to use cpp explicitely as a workaround, but I would like to remove this additional explicit preprocessing step.

Moreover, and even worse, if the variable i_n was an integer, then this particular test.for would compile and lead to a very vicious bug!

If think there is something wrong with ifort preprocessor. If there is no way that this situation can be handled by ifort, then the user should be informed by the output message.

A. Dechaume.

[Steven_L_Intel1]

The Fortran preprocessor follows Fortran syntax rules and what you have looks like continuation. To be honest, I don't like the way our fpp handles source lines - I think it should do a straight single-line substiution and not try to be clever about parsing and reassembling Fortran statements. But I don't see this changing.

I'll report this to the fpp developer and see if anything can be done about it.

[jimdempseyatthecove]

Although you are unable to change the source, what happens when you specify to compile .FORas F90/F95/F2003?

You will not be changing the source, rather you are changing compiler options.

When using fixed format...

How are you specifying left margin lead in spaces when the macro name is set flush to the left margin?

Jim

[a_d]

Hi Jim,

I'll try tomorrow to compile .for files as free format files and I'll let you know.

Are there any likely bad side effects to this?

In the actual code, this macro may contain optimization directives, such as CDIR$ IVDEP for instance (it may not be the most relevant example though), but no real fortran code whatsoever.

Antoine.

[jimdempseyatthecove]

You should be able to Fortran compile in fixed form but fpp parse in free form.

Thefortran command line option"-fpp:OptionSwitchHere" can be used.
Try"-fpp:free" or "-fpp:-free" (not sure about '-' sandwiched after the ':')
or "-fpp:f90" or "-fpp:-f90". Note, there is no white space following the ':'.

Also try '-fpp:m' or '-fpp:-m' (macros expanded anywhere in source file)

I do not have Mac/Linux with Fortran here so I cannot perform the command line option test.>>Are there any likely bad side effects to this?

There can be.

In fixed form you could have a mis-typed variable name that crosses the right margin column and is trucated into the correct name or benign name.

or continuation lines may at times present a problem.

>>this macro may contain optimization directives, such as CDIR$ IVDEP

Can you macro the text following "CDIR$ "?

#ifdef USE_IVDEP
#define M_IVDEP IVDEP
#else
#define M_IVDEP MESSAGE:' '
#endif

...
CDIR$ M_IVDEP

This does require changing your source.


Jim Dempsey

[a_d]

Unfortunately, none of the '-fpp:' kind of flags worked, I get a

test.for(3): warning #5117: Bad # preprocessor line

Alas, modifiying the source code is still not an option. :-/

Antoine.

[jimdempseyatthecove]

Antoine,

The compilation options should have worked (IMHO) but apparently the Fortran compiler is pre-processing a portion of the file before sending it on to the FPP preprocessor (the '_' in MACRO_0 being interpreted as a continuation character).

As an experiment try this round-about way:

Create the following file as FOO.F90

! FOO.F90
#include "offendingsourcefile.for"

Where "offendingsourcefile.for" contains the file name of the file with the objectionable macro

Now compile FOO.F90 as .f90 with FPP enabled and your other options (excepting for an option that specifies fixed format file).

If the above works then note that you have not modified the original source file so you are in compliance with this restriction. Effectively you have supplied compilation directives in a circuitouss manner.

Now assume the offending source files (offending may be too harsh ofword but descriptive none the less) have the file names:


abc.for, xyz.for and qwerty.for

You can create

abc.f90, xyz.f90 and querty.f90

containing

! abc.f90
#include 'abc.for'

! xyz.f90
#inclued 'xyz.for'

! qwerty.f90
#include 'qwerty.for'

Then change your project or make files to compile the .f90 stubs.

As a side note, if you are using MAKE files you could setup a rule to automatically create the xxx.f90 stub from the .for files.

.for.f90:
echo ! $*.f90 > $*.f90
echo #include '$*.for' >> $*.f90

Something like the above

or you could a .for.obj using the above echos followed by the compile line.

Jim Dempsey

[a_d]

Hi Jim,

thanks for your suggestions, unfortunately, as source modification is not an option, the same holds for the entire sources distribution with this respect.

A proper solution would be a correctly working ifort preprocessor, and not a workaround that in the end would return to an additional step such as the one we already have to use with ifort (thanks to 'cpp').

Antoine.