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]

Re: [Fwd: More cpplib Work]


Jeff,

Thanks for looking at this. In reponse to some of your comments:

>   In message <357D97DD.32C5FACB@cygnus.com>you write:
>   > Index: c-decl.c
>   > + #if USE_CPPLIB
>   > + #include "cpplib.h"
>   > + extern cpp_reader  parse_in;
>   > + extern cpp_options parse_options;
>   > + static int cpp_initialized;
>   > + #endif
> Shouldn't the extern decls be coming from a header file
> (possibly cpplib.h :-)?

These are actually owned by the front end and defined in c-common.c. There is no c-common.h.
I've asked a few times whether we want to make one, but no one has ever commented. Most of
the stuff in c-common.c seems to be declared in tree.h or c-tree.h.

>   I note some coding convention problems, but the old cpplib had the
> same problems.  It'd be nice to fix these, but that can/should be
> handled separately.

Please point them out as you see them. I'd be happy to fix them.

>    > +
>   > +      "%{E:"CPP_FOR_C"}"
>   > +      "%{!E:%{M:"CPP_FOR_C"}"
>   > +           "%{!M:%{MM:"CPP_FOR_C"}"
>   > +                "%{!MM:cc1 %i %1 \
>
> So, will CPP_FOR_C get substituted into these expressions, even with
> the quotes around it?  Does it work for both non-ANSI and ANSI compilers?

Actually CPP_FOR_C is *outside* the quotes and will get substituted. This relies on
concatenation of adjacent literals which works in ANSI. Good point about non-ANSI compilers.

> Why do we need the if-else-else?  Can't we just do a if-if-if?  Or
> does that screw up later tests?

Well, we only want to call cpp once if E or M or MM is specified. I couldn't come up with a
way to represent OR in this syntax. I would love to have a solution where the cpp invocation
is only needed once, then we could get rid of the macro. Of course I could get rid of the
macro anyway by just repeating the incantation. It may come to that if non-ansi compilers
won't concatenate the strings.

> Otherwise it looks pretty reasonable.  We should make a note in
> the LANGUAGES file so that the Ada, pascal & modula folks are aware
> of the lang_decode_option interface change.

OK.

Dave



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