Preprocessor problem w/ pgf77 6.1

Hi,

some of my programs don’t compile with the latest pgf77 6.1.
The reason is, I’ve discovered, that the preprocessor removes
newlines from the source. For instance, I have a vars.h for the
common blocks which contains the lines:

  • SM parameters

double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

On the first #include this comes out fine, but on the second one
the preprocessor substitutes

  • SM parameters double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

hence deleting two newlines. Obviously the compiler is then right
in asserting that

PGFTN-S-0038-Symbol, mz, has not been explicitly declared (squaredme/vars.h: 39)

Correct me if I’m wrong, but I don’t think the preprocessor is working
correctly here. I don’t have a “parameters” symbol declared to the
preprocessor, but even if, that doesn’t explain why the preprocessor
substitute works the first but not the second time.

Thanks for any info,

Thomas Hahn

Hi Thomas,

Can you post a code snipit which illustrates the behavior? I wrote up an example of what I think your doing, but my example works so I don’t think I’ve recreated the problem correctly.

Example test.F

      subroutine  foo 
#include "vars.h"
      end 

      subroutine bar
#include "vars.h"
      end

Where “vars.h” is:

* SM parameters

       double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

Also, are you using “-Mpreprocess” (which invokes pgprepro), using the interal pgf77 preprocesser (occurs when the file extension is “.F”), or some other method?

Thanks,
Mat

Hi Mat,


I’ve been able to narrow down the problem to a particular definition being present:
Try your test.F with the following vars.h:

* SM parameters

        double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

#ifndef s
#define s(i) (8*i+3)
#endif

Thomas

Hi Thomas,

This is an interesting one. What’s happening is that the preprocessor has partially matched the “s” at the end of “SM parameters” to the “s” macro since it ignores newline characters in case the rest of the macro continues on the next line. For example, if I change the header file to:

#ifndef s
#define s(i) (8*i+3)
#endif       

* SM parameters
(x)
        double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

The post-processed file becomes:

# 5 "./vars.h"
* SM parameter(8*x+3)
# 7
        double precision MZ, MZ2, MW, MW2, CW, CW2, SW2

The simple work around to this is to add a space after "* SM parameters ". This way the tokenizer can determine that “s” does not match “s(”. I’ll file a bug report on this. My only concern is if someone has come to rely on this “feature” and we break their code because of it. Hopefully we can come up with a solution to accomodate both.

  • Mat

Mat-- I beg to differ, this is quite a serious breach of preprocessor parsing.
The s in “parameters” is clearly not a single entity and must not be
substituted by the preprocessor in the same way as, say, the abc in

#define abc(x) x
* xyzabc
       double precision a, b, c

wouldn’t be substituted. Besides, this definition of s(x) is in my code
for quite a while already, and no pgf77 version so far has had trouble
with it.

I am quite uninclined to use a clumsy workaround, but at the present
moment can recommend to my users to use pgf77 version before 6.1
or a different compiler altogether.

Hi Thomas,

You correct that I was mistaken that this might be a normal behavior. I just got word for our compiler team that this is a regression from 6.0. They believe they have a fix which should be available in the 6.1-3 compiler which is expected to be released on March 2nd, 2006.

I apologize for any inconvenience this has caused and thank you for bring this issue to our attention.

  • Mat