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]



  In message <357E9BB5.83D57852@cygnus.com>you write:
  > These are actually owned by the front end and defined in
  > c-common.c. There is no c-common.h.
Ah.  OK.

  > 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 don't remember anyone asking about this.  Then again, it could
easily get lost in the email flood.

It's probably the right thing to do long term.  But we've still got
to finish up system.h/toplev.h :-)

So, I guess it's OK as-is.

  > >   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.
THe ones that come immediately to mind are braces that are on lines
with code.  ie

if (blah) {
}

Instead of

if (blah)
  {
  }


cppp.c and its derative cpplib files are riddled with this stuff.

A search for ") {" should turn up most of them.  Again, I realize
this is stuff you inherited from existing code, so it's not quite
as important that you fix it now :-)


  > >   > +           "%{!M:%{MM:"CPP_FOR_C"}"
  > > 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 substitute.
  > This relies on concatenation of adjacent literals which works in
  > ANSI. Good point about no n-ANSI compilers.
Ah, yes, I see it now.  God I hate this code.

Yea, we need to do something about the string concat issue since we
do need gcc to be able to bootstrap from non-ansi compiler.

  > > 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.
Ah.  Yes, I see the problem.    I'm not aware of an OR in the specs
syntax.  Bummer.

jeff


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