Re: Solaris pragma macro expansion

[Zack Weinberg <zack at codesourcery dot com>]

Joseph S. Myers wrote:
> There is a new argument to cpp_register_pragma - it's the
> c_register_pragma wrapper that gets a new counterpart.  Now, there
> is no API guarantee for the back-end interface either, so I can
> certainly change things to have an additional argument to
> c_register_pragma; I suppose the original idea was to reduce churn
> in other back ends.

Ok, sorry, I misread the patch.  I thought it was exactly the other
way around.  At this stage, reducing churn in other back ends is a
Good Thing, so I withdraw this objection (but you might consider
filing a 4.1 wishlist bug to collapse the two interfaces together.)


> I haven't been testing this patch series with C++ (the first patch
> adding the port had an ICE building libstdc++-v3, and I wanted to
> get things closer to a known working state before investigating that
> in case some part of the port not yet merged to mainline contained
> the fix for the ICE).  I think the macros will be expanded but in
> the wrong context of macro definitions (i.e. y12 won't be seen as
> defined in C++).  Any suggestions on good ways to fix this?

As a stopgap measure, suggest ignoring the macro-expansion-enabled
flag on individual pragmas when called from
cpp_handle_deferred_pragma.  This will produce behavior which is
no worse than the status quo.

The Right Thing, in my opinion, is to tokenize #pragma arguments up
front, instead of capturing the line in a pseudo-string constant and
tokenizing it only when cpp_handle_deferred_pragma eventually gets
called.  That would cause macro expansion to happen in the right
context.  However, you then have the problem of how to encapsulate the
resultant token stream for later processing.  The way I'd *like* it to
work is that the front end sees a token sequence like this

   CPP_PRAGMA<align> ( 12 ) ;

where CPP_PRAGMA<align> is a single synthetic token whose value is a
function pointer to the appropriate pragma handler, the ( 12 ) tokens
are the (macroexpanded) arguments, and the semicolon is also
synthetic.  The problem with this is that you now have to provide a
variant c_lex for the C++ front end which reads from the token buffer
instead of calling into cpplib, and intercepts the terminating
semicolon and provides instead an infinite stream of CPP_EOF tokens
(and then that has to be reset somehow for the next #pragma).  All
this smells like 4.1 material to me.

zw