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


I see serious design problems with this patch.

For one thing, you're working way too hard.  Others have already
pointed out that this breaks every target that defines a target-
specific #pragma.  But the only reason that happened is because you
introduced c_get_token.  Instead, define c_lex to be the name of the
function that #pragma handlers call to get their tokens (which is
already true) and then cause the C and C++ front ends to provide
versions of that interface that do the Right Thing for their token
queues.  In other words, move the existing c_lex() to a C-front-end
specific file, and add a version to the C++ front end that works when
called by #pragma handlers.  You may need to adjust other callers of
c_lex, but I don't think there are too many of them left.

Secondly, I do not like an approach that introduces two separate
#pragma dispatchers.  cpplib is always going to have to look up
#pragmas in order to handle those that affect the preprocessor's
state, so that dispatcher has to remain, so it should be responsible
for mapping *all* pragmas to their handlers.  For handlers that
execute during translation phase 7, what you should do is save the
function pointer in the token's payload (instead of the identifier).
Then all the C and C++ front ends have to do when they encounter a
CPP_PRAGMA token is call the function pointer inside.

Third, you've introduced further divergence between the C and C++
front ends' pragma handling.  This is a step in the wrong direction.
You should be working toward just one pragma-handling style for both
front ends.  (In other words, I don't want to see init_pragma growing
arguments.)

Fourth, as a comparatively minor nitpick, I would prefer that you used
a different token type to indicate end of pragma arguments.
CPP_PRAGMA with a null payload is just too clever.  I suspect you
could get away with using CPP_EOF, which would have the advantage of
requiring no translation for target pragma handlers to get what
they're already expecting.

zw


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