Steven Bosscher <address@hidden> writes:
Perhaps we would transform
#pragma foo bar baz
into
__builtin_pragma foo bar baz;
and feed that to phase 7.
With the GOMP project we still haven't found out how to lex/parse OMP
directives. That bothers me a bit so I've been giving this a lot of
thought lately, but I still don't see how it can be done without major
changes. We need to figure this out before we can hack the front ends.
I was hoping maybe you can give me some help here because you probably
have the best idea of what exactly you mean with "phase 7" and you know
cpplib best :-)
...
After re-reading that mail from you to gcc@, I think you had something
else in mind: Not builtin _functions_, but rather some kind of token
__builtin_pragma, and a regular stream of tokens following that. If I
understand your idea correctly, this means that the parser would be
(more) responsible for handling pragmas. This would be ideal to us.
However, I and probably most others in the GOMP project, are not exactly
C/C++ language lawyers. At least I don't have a clue what "phase 7"
means, and how it is related to recursive descent parsing.
"Phase 7" is a term from the C standard. The short version is that it
refers to the parsing phase of translation (and everything after that).
You've correctly understood my suggestion. I had in mind that cpplib
would, upon encountering a #pragma, first check whether it was a
#pragma that affects preprocessor behavior. If not, it would inject
the token __builtin_pragma into its output stream, then pass all the
tokens following the #pragma on unchanged, and finally inject a ;
token at the end of the directive line.
The C parser would then interpret __builtin_pragma as a _keyword_, and
expect a stream of tokens following - with whatever syntax and
semantics are necessary - until it reached the trailing semicolon, at
which point it would go back to the normal grammar.
C99's _Pragma() would get the same treatment, except that its argument
would be unstringified first.
The only thing this has to do with recursive descent parsing is that
this suggestion would be a major major PITA to implement with the
current yacc-based C parser. So I would suggest that the GOMP project
help out with the existing plans to reimplement the C parser in
recursive descent style. Neil is, or was, working on this; you should
talk to him.
zw
_______________________________________________
Gomp-discuss mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/gomp-discuss