This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New pragma handling mechanism.


Richard Henderson wrote:

Indeed, I don't like it at all.  We've already got one big basket
data structure in the front end, and it's called "tree".  We don't
need another big basked data structure called "pragma".

Whereas I would rather have multiple smaller baskets, with more clearly defined roles. To me, optionally attaching a (list of) "struct pragma *" to a a statement in the front end, and letting the gimplifier deal with it later seems very tidy. Again, this preserves the high-level structure of the user input in the front-end. Certainly, the fact that "everything is a tree" is something we're trying to get away from.


You asked "how is parsing not general?" It's general, but it's not very nicely encapsulated. In particular, since the C and C++ front ends look to be staying separate for the forseeable future, they've got different parsers, and their internal representations are already divergent. I'm not sure that a pragma handler can be easily written to apply to these different IRs, so if the handler is parsing the subsequent construct, it's probably going to have to pass in some representation of the #pragma so that the front-end's parsing routine can do the right thign.

It also sounds like, for C++ templates, you're planning on preserving the pragma in some form, so that you can substitute into it at instantiation-time. That is just what I would expect. But why not save it as its own data structure, rather than as a tree?

You also said "I don't like trying to design for some uknown future requirements". I just see it as a basic encapsulation step. I also have experience with adding new #pragmas to a front-end that does this, and found it convenient.

I certainly wouldn't want to see us fail to support OpenMP because of a disagreement about internal representation. Do any of the other C/C++ maintainers have input?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]