This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Best way to remove cpp0
- To: Joern Rennecke <amylaar at onetel dot net dot uk>
- Subject: Re: Best way to remove cpp0
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Mon, 15 Oct 2001 07:40:42 +0100
- Cc: Zack Weinberg <zack at codesourcery dot com>, joseph at daikokuya dot demon dot co dot uk,gcc at gcc dot gnu dot org
- References: <20011012223509.A30940@daikokuya.demon.co.uk> <200110150041.BAA04736@meolyon.local>
Joern Rennecke wrote:-
> The Gnu coding standards say you shouldn't make the program behaviour
> dependent on the name the program is invoked with.
I don't believe that was my proposal - gcc and g++ have always done
different things.
> This is just asking for Heisenbugs. You want to be able to feed the .i
> file into cc1 with the same result as when you invoke the driver with
> --save-temps, so you better actually feed the .i file into cc1 the first
> time too.
Right; but that is precisely Joseph's suggestion, no?
> On the other hand, you are going to use a binary that has extra functionality
> that is seldom used (stand-alone preprocessing) for another task that
> happens very often. We currently don't have a sufficiently advanced
> profile based feedback infrastructure to avoid increasing the working
> set size by interleaving used code with unused code from the extra
> functionality.
It's very small. I wouldn't call the amount of code in cppmain.c
significant.
> I can't follow you here. Why is it posible to make a cc1-cum-cpp binary
> with more efficient preprocessed output more easily than a single-purpose
> cpp binary?
Because it is in cppmain.c, which uses the library's external
interface. If moved into the library, things that are currently done
with function calls etc. could be done by derefencing pfile, for
example.
Neil.