This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PCH] driver, documentation
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: Stan Shebs <shebs at apple dot com>
- Cc: Mike Stump <mrs at apple dot com>, Geoffrey Keating <geoffk at redhat dot com>,gcc-patches at gcc dot gnu dot org
- Date: Mon, 19 Aug 2002 19:27:47 +0100
- Subject: Re: [PCH] driver, documentation
- References: <FEF7DCAA-B398-11D6-943C-000393941EE6@apple.com> <3D6131E2.3090309@apple.com>
Stan Shebs wrote:-
> Mike Stump wrote:
>
> >I was wondering about flags like -fvolatile, -O2, -O0, -g and
> >-ffast-math? -UMACRO? Do they rule out pch? Should they?
> >I am thinking about C++ where it is possible to have significant
> >portions of code for an application in header files.
>
> Ideally, you'd keep around tree rather than RTL, so most backend flags
> shouldn't matter. The most problematic backend flags are the ones that
> define cpp macros, so that would include -On because of __OPTIMIZE__
> (I think we get this one wrong now). It would be useful to have some
> way of knowing or indicating flags that don't affect a precomp, because
> it's too restrictive otherwise - consider a -Wxxx passed only to some
> files in a project.
You could do:
1) The set of macros defined in the PCH file after command line
processing must be a subset of those after the new command line.
2) Any new macro definitions did not have the macro names' identifiers
in the hash table *at all*.
Since we hash every identifier, this will work, assuming you store the
full hash table in the PCH. I don't think you can settle for a weaker
set of restrictions, and these are the weakest that are easily
implemented.
Neil.