ifort-14.0 -cpp not referentially transparent

[Brown__Jed]

$ cat macro.F90
#define X_LT(a) (a < 3)
#define X_GE(a) (!X_LT(a))

#if !X_LT(3)
#warning no problem here
#endif

#if X_GE(3)
#warning "syntax error" with ifort, not with gfortran
#endif

$ ifort -c macro.F90                                                                                                                                                                                                          
macro.F90(5): #warning:  no problem here

macro.F90(8): #error: #if: syntax error.
macro.F90(9): #warning:  "syntax error" with ifort, not with gfortran

I do not think this is useful preprocessor behavior.  This came up in a version check macro shared between C and Fortran. Changing to #define X_GE(a) (0 == X_LT(a)) is a workaround.

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.080 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

[Lorri_M_Intel]

If I may double-check my understanding please..
The actual problem that you are having is the syntax error on the line " #if X_GE(3) ", and the other messages are fine.

The exclamation point is a Fortran comment character. 
The Fortran preprocessor (despite its similarity to the C preprocessor) will treat the exclamation point as a comment delimiter, which does funny things to the macro expansion for your macro X_GE

You can pass an option to the Fortran preprocessor (fpp) to ignore the exclamation point, as:

                        ifort -Qoption,fpp,-f_com=no  myfile.F

                                            --Lorri 

[Yuan_C_Intel]

Hi, Lorri

Thank you for anwering this.

But how does it explain Line 05 works fine? I verified gfortran will not report an error in this case.

Thanks,

Yolanda

[Brown__Jed]

The other warnings are just to show which lines have been reached. My concern is that '!' is being interpreted as a comment character inconsistently.  It should either always be a comment or never be a comment.  I would prefer never so that logical expressions can be written more naturally, but consistency is most important.

[Lorri_M_Intel]

Hi Yolanda -

   I think it is as JedB. suggested ... inconsistent behavior in fpp between the processing of the #define and the processing of the #if.

                    --Lorri

[Brown__Jed]

Is this something that Intel intends to fix in the next release, or is this haphazard inconsistency something that will remain indefinitely? The fact that the Fortran standard doesn't say anything about a preprocessor means there is no formal specification and each vendor can make their own ad-hoc choices. But many projects use the preprocessor, so this fragmentation leads to portability problems. Short of a formal spec, it would be useful if the major vendors could informally agree on semantics.

[Yuan_C_Intel]

Hi, Jed Thank you for the reminder on this. Yes, I agree we should make this consistent at least. I have entered this in our problem-tracking system. I will notfy you when I have an update on the progress of the issue. For now you may have a try with Lorri's work-around. Will it work for you? Thanks, Yolanda

[Yuan_C_Intel]

Hi, Jed On Linux, the comman line should be: ifort -c -fpp -Qoption,fpp,-f_com=no macro.f90 I verified this works. Thank you Yolanda

[Brown__Jed]

I worked around the issue by avoiding use of ! entirely. A library header that can be included by users cannot depend on compiler options like this.