[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: Changes to gcc 3.x to invoke an external cpp (updated patch 2)
From:       Neil Booth <neil () daikokuya ! demon ! co ! uk>
Date:       2002-02-28 22:27:15
[Download RAW message or body]

Ashif S. Harji wrote:-

> We have tried to address all these issues.  See our message below.

Great, thanks.

> > However, I'm not sure whether this will work for 3.2.  I want the
> > separate preprocessor to die completely in 3.2, but I'll try to retain
> > your semantics if possible by passing it through cc1 twice, I guess.
> 
> We'd be interested in hearing what you have in mind for retaining our
> semantics in 3.2.  As well, we'd be happy to work with you to achieve the
> desired behavior.

Hmmm.  As has been discussed at various times over the past 6 months,
we probably want to remove "cpp0" entirely, and have preprocessed output
done, where necessary, either

1) Through 2 invocations of cc1 (rather than a cpp0 / cc1 combo as now),
   or
2) Through a single "clever" cc1 that both does preprocessed output and
   compilation (if necessary).

From my vague understanding of your situation, 2) would stuff you
entirely.  I even think 1) is a loser for you.  I'm not sure which of 1)
or 2) will ultimately prevail, but I do know that a patch for 1) should
be fairly straight-forward, and I was even thinking of doing one this
weekend if I found time.

More specifically, to get 1) and 2) to work, I would pass the -E option
through to the front ends.  Currently the drivers swallow the -E option,
and through specs do the extra invocation necessary.  But if cpp0 dies,
then cc1 needs to know whether it is being invoked as a compiler, or as
a preprocessor.  I was intending to have the -E option passed through to
the front ends to distinguish these two situations, so they could behave
appropriately.  Supposing I did this, which is not unlikely, what would
you do?  Would it be possible to rescue your situation at all?

If not, then I should be honest and say that I don't think this patch is
appropriate (as it would only enable the behaviour you seek for 3.1,
having already been lost in 3.0 and hypothetically 3.2).  If you can
survive, then that's great.

> +
> + @item -no-integrated-cpp
> + @opindex no-integrated-cpp
> + Invoke the external cpp during compilation.  The default is to use the
> + integrated cpp (internal cpp).  This option also allows a user-supplied cpp
> + via the @option{-B} option.  This flag is applicable in both C and C++ modes.

I've not checked your "spec" changes in detail, but they look good at a
glance.  I want to add to your description above that this feature will
be maintained where possible, but may not be available in future, owing
to changes we might want to make to GCC's infrastructure.  In addition
to the changes to CPP I outline above, you may have noticed a thread in
the last 24 hours about installation changes that sounded like it could
cause removal of the -B option (whether that is actually the case,
I don't know).  The point is that we don't want to restrict our future
freedom of maneouvre.

So, please let me know how the death of cpp0 would affect you.

Neil.
[prev in list] [next in list] [prev in thread] [next in thread]