PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Preprocessor problem w/ pgf77 6.1
Goto page 1, 2  Next
 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling
View previous topic :: View next topic  
Author Message
thahn



Joined: 21 Jul 2004
Posts: 3

PostPosted: Tue Jan 31, 2006 5:08 am    Post subject: Preprocessor problem w/ pgf77 6.1 Reply with quote

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
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5952
Location: The Portland Group Inc.

PostPosted: Wed Feb 01, 2006 10:00 am    Post subject: Reply with quote

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
Code:
      subroutine  foo
#include "vars.h"
      end

      subroutine bar
#include "vars.h"
      end

Where "vars.h" is:
Code:

* 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
Back to top
View user's profile
thahn



Joined: 21 Jul 2004
Posts: 3

PostPosted: Thu Feb 02, 2006 2:43 am    Post subject: Reply with quote

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:

Code:
* SM parameters

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

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


Thomas
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5952
Location: The Portland Group Inc.

PostPosted: Thu Feb 02, 2006 12:26 pm    Post subject: Reply with quote

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:
Code:
#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:
Code:
# 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<space>" 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
Back to top
View user's profile
thahn



Joined: 21 Jul 2004
Posts: 3

PostPosted: Mon Feb 06, 2006 11:19 am    Post subject: Reply with quote

mkcolg wrote:
The simple work around to this is to add a space after "* SM parameters ". This way the tokenizer can determine that "s<space>" 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-- 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
Code:
#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.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © phpBB Group