Re: Changes to gcc 3.x to invoke an external cpp (updated patch 2)

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Mar 11, 2002 at 11:03:13PM -0500, Peter A. Buhr wrote:
> 
>    The absolute best solution to my problem is to incorporate our
>    (or something like our) concurrency constructs into the C++
>    programming language and have the compiler do what our translator
>    does now. This would have the additional benefit of enabling the
>    compiler to perform sequential optimizations that do not invalid
>    a correct concurrent program and to generate any necessary memory
>    synchronization instructions. In other words, if the compiler
>    knows the program is concurrent, and has some reasonable
>    concurrent constructs to work with, it can generate
>    highly-optimized safe concurrent-programs.

We are open to proposals for extensions to the language.  You're right
in thinking that the barrier to entry here is quite high; we have a
bad history of poorly-thought-out extensions causing problems down the
road.  The current thinking is that a brand-new extension needs to be
specified carefully enough that we could propose it to the language
standards committee with no additional work.

...
>    Ok, enough groundwork. Here's my opening design suggestion to
>    make the old and new compatible. The approach is to introduce the
>    notion of user-level preprocessors that are invoked by the
>    compiler *after* the traditional cpp preprocessing.
...
>    So here's the outline of how this might work. Imagine a
>    "-preprocessor xxx" flag to the compiler driver. When this flag
>    is present, the driver first uses cc1 with -E (or the equivalent
>    thereof) to perform the normal C preprocessing step on the given
>    source file. The output of preprocessing is then put into a
>    temp-file (as would be done for the "-save-temps" flag).  The
>    driver then invokes the preprocessor "xxx", passing it the
>    temp-file as input and another temp-file to write the output,
>    along with all the flags appropriate to cpp. (These flags are
>    important to all preprocessing steps.)  

This could definitely be done.  It works with both the current setup
(cpp0 as a separate executable) and the proposed one (merged into cc1).
I don't think there'd be any problem expressing it within the specs
file, either.

>    If multiple "-preprocessor" flags are present on the command
>    line, the driver invokes the preprocessors in the order given.

That might be difficult to express with the current driver, although
if we ever get around to rewriting it as Neil proposed last year, it
would be doable.  I don't think you need it right now, though?

zw