Re: -no-integrated-cpp flag

[Neil Booth <neil at daikokuya dot co dot uk>]

Ashif S. Harji wrote:-

> We are looking into producing a patch for the -no-integrated-cpp flag in
> gcc-3.3 and we had a couple of questions.
> 
> 1) The save-temps flag with respect to preprocessing is currently implemented
>    by invoking the preprocessor and compiler in two separate steps.  Is this
>    behaviour to be maintained in future releases or is save-temps with respect
>    to preprocessing going to be integrated into the compiler?

To claim I know for sure would be lying.  However, I'd be happy to bet
evens that it stays as two steps 8-)

> 2) Assuming that the save-temps with respect to preprocessing will continue to
>    be implemented using two steps, why is there a difference between the way it
>    is implemented in gcc versus g++ or objc?
> 
>    In gcc, first preprocessing occurs by calling '(trad_capable_cpp)' and then
>    compiling occurs by calling 'cc1' with '-fpreprocessed' (see gcc.c for more
>    details).
> 
>    In g++, preprocessing occurs by calling 'cc1plus' with the '-E' flag
>    and then compiling occurs by calling 'cc1plus' again, but this time
>    with '-fpreprocessed' (see cp/lang-specs.h for more details).
>    Similarly for objc.

Hmmm.  I think you're confused about something but I can't tell quite
what it might be, so I'll describe a few random things and hope that
something might click or you can elaborate on what you don't see
eye-to-eye with me.

There is no "CPP" that does everything per-se.  There is a cpp library
that is statically linked with each C front end (C, C++ and Obj-C), that
if invoked in various modes does various different things.  In one
mode or another it should be able to do whatever the caller wants.

Now, Obj-C wants the cpp library to understand Obj-C constructs
(particularly w.r.t. the @ token).  In the same vein, C++ has more than
its fair share of demands about how preprocessing should be done.  How
are these differences communicated to the library?  At present, it's a
kludge of both 1) Each front end has its own special code linked, e.g.
the Obj-C front end sets "flag_objc" to be 1 in its initialization hook.
Similarly the C++ front end links its own initialization hook s.t.
things get initialized the way C++ wants it.  In addition / at the same
time, the driver indicates to the main compiler binary what it wants via
e.g. "-lang-objc" flag.  There is no such flag for the C++ compiler; it
can only achieve its objectives by being a separately linked binary with
a different initialization hook that sets things up the way it wants.

When we have the one-true-front-end-that-does-everything (ahem), this
fudge won't work, and the only way for the driver to indicate that it
wants a particular preprocessing mode will be via a switch such as
"-lang-objc" or "-lang-cxx".  The binary invoked will be the same
binary.

-traditional preprocessing doesn't exist in C++ land, which started
(theoretically at least) with an ISO standard.  It only applies to
the C front end and (therefore in a hand-wavy kinda way) to the ObjC
front end, which is supposed to be a superset of the C front end.

The reasons I give above are why the binaries are invoked differently
at present.  Ultimately, it will be a single link-time binary, whose
main difference in invocation would be the presence or absence of
"-lang-objc" and/or "-lang-cxx".  In other words, cc1, cc1plus and
cc1obj will not be distinct, but the same binary.

The trad_capable_cpp spec is supposed to capture what cc1 might need to
do traditional preprocessing if requested, and to DTRT if not requested.

-fpreprocessed changes the behaviour of the preprocessor phase, so that
no transformations are applied on the (preprecessed) input that would
be applied were it not preprocessed input.  As a simple example, no
macros are recognized, not even __LINE__, and escaped newlines and
trigraphs are ignored. 

The C++ specs are

       %{save-temps:cc1plus -E %{!no-gcc:-D__GNUG__=%v1}\
		%(cpp_options) %2 %b.ii \n}\
      cc1plus %{save-temps:-fpreprocessed %b.ii}\
	      %{!save-temps:%(cpp_unique_options)
	      %%{!no-gcc:-D__GNUG__=%v1}}\
	%(cc1_options) %2 %{+e1*}\

The -E option is only given if -save-temps.  Otherwise it is one-phase
translation with cc1plus, cpp_unique_options and cc1_options, as indicated
from line 3 onwards with !save-temps.

>    Is there a reason why 'cpp' is not invoked to handle the preprocessing for
>    all three of the languages? That is, does the integrated cpp supply
>    functionality that is unavailable in the separate cpp, and that is need by
>    C++ and objc? Or is the separate cpp used by gcc soon to be replaced by
>    'cc1 -E'?
> 
> Once we know the answers to these questions, we can proceed with some
> suggestions.

There is no "cpp"; there are only front-end binaries (cc1, cc1plus
and cc1obj) that, if inovked with -E, rather than compiling, give
preprocessed output (at present, according to their particular language
semantics, though as implied above, ultimately there will only be one
binary that accepts -lang-objc and / or -lang-cxx or neither) which can
then be re-input to a new process without -E and with -fpreprocessed
to be compiled if you desire.

Hence why CPP is "integrated".  If not invoked with -E, the integrated
preprocessor passes tokens directly (i.e. not via an intermediate file)
to the compiler front end.  All this occurs within the same binary (cc1,
cc1plus or cc1obj).

I hope the above waffle has helped to clarify things.  Feel free to
ask more questions.  Really, it isn't much different to how things
were before, just that there is no separate preprocessing-only binary;
the relevant front-end does preprocessed output if requested.

Neil.