-no-integrated-cpp flag

-no-integrated-cpp flag

[Neil Booth]

Hi Ashif,

Would you mind producing a patch for 3.3?  After 3.3 we'll maintain
it ourselves as part of the compiler I think.  Most of the option
rearranging has happened, and -traditional is now integrated too.

Thanks,

Neil.

Re: -no-integrated-cpp flag

[Ashif S. Harji]

Neil,

Yes, we would like to create a patch for 3.3 for the -no-integrated-cpp
flag.  We will take a look at what has changed in 3.3 and get back to you
so we can decide how to proceed.

thanks,
ashif.

On Tue, 19 Nov 2002, Neil Booth wrote:

> Hi Ashif,
>
> Would you mind producing a patch for 3.3?  After 3.3 we'll maintain
> it ourselves as part of the compiler I think.  Most of the option
> rearranging has happened, and -traditional is now integrated too.
>
> Thanks,
>
> Neil.
>

Re: -no-integrated-cpp flag

[Ashif S. Harji]

Neil,

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?

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.

   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.

thanks,
ashif.

On Tue, 19 Nov 2002, Neil Booth wrote:

> Hi Ashif,
>
> Would you mind producing a patch for 3.3?  After 3.3 we'll maintain
> it ourselves as part of the compiler I think.  Most of the option
> rearranging has happened, and -traditional is now integrated too.
>
> Thanks,
>
> Neil.
>

Re: -no-integrated-cpp flag

[Neil Booth]

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.

Re: -no-integrated-cpp flag

[Neil Booth]

Neil Booth wrote:-

> Hi Ashif,
> 
> Would you mind producing a patch for 3.3?  After 3.3 we'll maintain
> it ourselves as part of the compiler I think.  Most of the option
> rearranging has happened, and -traditional is now integrated too.

There's very little time left for this.

Neil.

Re: -no-integrated-cpp flag

[Ashif S. Harji]

Neil,

Sorry for the delay, we've been quite busy since the new year.  We're
actually working on the changes, so your message is timely.  Porting the
flag to 3.3 is done and we are in the process of confirming that, given
the changes in 3.3, the flag is still sufficient for our needs.  We expect
to finish within two weeks.  Is that time frame reasonable?

ashif.


On Mon, 24 Feb 2003, Neil Booth wrote:

> Neil Booth wrote:-
>
> > Hi Ashif,
> >
> > Would you mind producing a patch for 3.3?  After 3.3 we'll maintain
> > it ourselves as part of the compiler I think.  Most of the option
> > rearranging has happened, and -traditional is now integrated too.
>
> There's very little time left for this.
>
> Neil.
>

Re: -no-integrated-cpp flag

[Neil Booth]

Ashif S. Harji wrote:-

> 
> Neil,
> 
> Sorry for the delay, we've been quite busy since the new year.  We're
> actually working on the changes, so your message is timely.  Porting the
> flag to 3.3 is done and we are in the process of confirming that, given
> the changes in 3.3, the flag is still sufficient for our needs.  We expect
> to finish within two weeks.  Is that time frame reasonable?

Sooner if possible; we don't want to leave it too close to release.
Please keep an eye on the lists.

Neil.

Re: -no-integrated-cpp flag

[Ashif S. Harji]

Neil,

The porting is finished, except for one outstanding issue.  The name of
the flag, '-no-integrated-cpp', could better reflect the changes to the
compiler.  We suggest renaming the flag to '-no-integrated-preprocessing'.
Once you let us know if you would prefer to go with the old or new flag
name, I will do the final build and test and send in the patch.

thanks,
ashif.

On Tue, 25 Feb 2003, Neil Booth wrote:

> Ashif S. Harji wrote:-
>
> >
> > Neil,
> >
> > Sorry for the delay, we've been quite busy since the new year.  We're
> > actually working on the changes, so your message is timely.  Porting the
> > flag to 3.3 is done and we are in the process of confirming that, given
> > the changes in 3.3, the flag is still sufficient for our needs.  We expect
> > to finish within two weeks.  Is that time frame reasonable?
>
> Sooner if possible; we don't want to leave it too close to release.
> Please keep an eye on the lists.
>
> Neil.
>

Re: -no-integrated-cpp flag

[Neil Booth]

Ashif S. Harji wrote:-

> 
> Neil,
> 
> The porting is finished, except for one outstanding issue.  The name of
> the flag, '-no-integrated-cpp', could better reflect the changes to the
> compiler.  We suggest renaming the flag to '-no-integrated-preprocessing'.
> Once you let us know if you would prefer to go with the old or new flag
> name, I will do the final build and test and send in the patch.

I don't want to change the name of the switch now.

Neil.

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Neil Booth]

Ashif S. Harji wrote:-

> The patches are below.  As you requested, I have kept the same name.  I
> noticed something unusual that I wanted to bring to your attention.

Thanks a lot; I'll apply this now.

> Apparently, the -traditional-cpp flag with gcc generates and saves the
> basename.i file.  I have maintained this behaviour with my patches, but it
> seemed unusual to me and it is different from the behaviour of gcc-3.2.

It should be generated, but I guess it should be deleted afterwards too.

Neil.

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Peter A. Buhr]

   > Apparently, the -traditional-cpp flag with gcc generates and saves the
   > basename.i file.  I have maintained this behaviour with my patches, but it
   > seemed unusual to me and it is different from the behaviour of gcc-3.2.

   It should be generated, but I guess it should be deleted afterwards too.

If you decide to change this, let us know because we have to adjust our patch
accordingly. I think Ashif could make this correction and include it in our
patch, assuming you want the changed behaviour for the gcc -traditional-cpp
flag, i.e., delete the file by making it a temporary file. It's your call, but
we could do it quickly because Ashif has all this stuff in his head at the
moment and then have only one patch.

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Neil Booth]

Peter A. Buhr wrote:-

>    > Apparently, the -traditional-cpp flag with gcc generates and saves the
>    > basename.i file.  I have maintained this behaviour with my patches, but it
>    > seemed unusual to me and it is different from the behaviour of gcc-3.2.
> 
>    It should be generated, but I guess it should be deleted afterwards too.
> 
> If you decide to change this, let us know because we have to adjust our patch
> accordingly. I think Ashif could make this correction and include it in our
> patch, assuming you want the changed behaviour for the gcc -traditional-cpp
> flag, i.e., delete the file by making it a temporary file. It's your call, but
> we could do it quickly because Ashif has all this stuff in his head at the
> moment and then have only one patch.

If Ashif can provide a patch that fixes it; that's great.  Please post
it a.s.a.p. provided you've bootstrapped and regtested it.

The previous patch didn't apply cleanly to 3.3 FWIW; I'm not sure why.
I'm compiling it at the moment so I've not applied it.  I'll hold off
for a while.

Neil.

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Ashif S. Harji]

> > Apparently, the -traditional-cpp flag with gcc generates and saves the
> > basename.i file.  I have maintained this behaviour with my patches, but it
> > seemed unusual to me and it is different from the behaviour of gcc-3.2.
>
> It should be generated, but I guess it should be deleted afterwards too.

In that case, consider the patch below for gcc.c instead.  I am running
the tests at the moment.

1>@awk[182]% diff -c3p gcc-20030224/gcc/gcc.c test/gcc-20030224/gcc/gcc.c
*** gcc-20030224/gcc/gcc.c	Thu Dec 12 19:17:19 2002
--- test/gcc-20030224/gcc/gcc.c	Wed Feb 26 16:36:28 2003
*************** static const struct compiler default_com
*** 857,867 ****
        %{!E:%{!M:%{!MM:\
            %{traditional|ftraditional:\
  %eGNU C no longer supports -traditional without -E}\
! 	  %{save-temps|traditional-cpp:%(trad_capable_cpp) \
! 		%(cpp_options) %b.i \n\
! 		    cc1 -fpreprocessed %b.i %(cc1_options)}\
! 	  %{!save-temps:%{!traditional-cpp:\
! 		cc1 %(cpp_unique_options) %(cc1_options)}}\
          %{!fsyntax-only:%(invoke_as)}}}}", 0},
    {"-",
     "%{!E:%e-E required when input is from standard input}\
--- 857,867 ----
        %{!E:%{!M:%{!MM:\
            %{traditional|ftraditional:\
  %eGNU C no longer supports -traditional without -E}\
! 	  %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \
! 		%(cpp_options) %{save-temps:%b.i} %{!save-temps:%g.i} \n\
! 		    cc1 -fpreprocessed %{save-temps:%b.i} %{!save-temps:%g.i} %(cc1_options)}\
! 	  %{!save-temps:%{!traditional-cpp:%{!no-integrated-cpp:\
! 		cc1 %(cpp_unique_options) %(cc1_options)}}}\
          %{!fsyntax-only:%(invoke_as)}}}}", 0},
    {"-",
     "%{!E:%e-E required when input is from standard input}\
*************** static const struct option_map option_ma
*** 965,970 ****
--- 965,971 ----
     {"--library-directory", "-L", "a"},
     {"--machine", "-m", "aj"},
     {"--machine-", "-m", "*j"},
+    {"--no-integrated-cpp", "-no-integrated-cpp", 0},
     {"--no-line-commands", "-P", 0},
     {"--no-precompiled-includes", "-noprecomp", 0},
     {"--no-standard-includes", "-nostdinc", 0},

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Ashif S. Harji]

The patch passed bootstrap and testing.

Bootstrapping and Testing:

On i686-pc-linux-gnu:
   - bootstrap was successful
   - no changes in testsuite results when compared to original (gcc-20030224 snapshot)


On Sat, 1 Mar 2003, Ashif S. Harji wrote:

>
> > > Apparently, the -traditional-cpp flag with gcc generates and saves the
> > > basename.i file.  I have maintained this behaviour with my patches, but it
> > > seemed unusual to me and it is different from the behaviour of gcc-3.2.
> >
> > It should be generated, but I guess it should be deleted afterwards too.
>
> In that case, consider the patch below for gcc.c instead.  I am running
> the tests at the moment.
>
> 1>@awk[182]% diff -c3p gcc-20030224/gcc/gcc.c test/gcc-20030224/gcc/gcc.c
> *** gcc-20030224/gcc/gcc.c	Thu Dec 12 19:17:19 2002
> --- test/gcc-20030224/gcc/gcc.c	Wed Feb 26 16:36:28 2003
> *************** static const struct compiler default_com
> *** 857,867 ****
>         %{!E:%{!M:%{!MM:\
>             %{traditional|ftraditional:\
>   %eGNU C no longer supports -traditional without -E}\
> ! 	  %{save-temps|traditional-cpp:%(trad_capable_cpp) \
> ! 		%(cpp_options) %b.i \n\
> ! 		    cc1 -fpreprocessed %b.i %(cc1_options)}\
> ! 	  %{!save-temps:%{!traditional-cpp:\
> ! 		cc1 %(cpp_unique_options) %(cc1_options)}}\
>           %{!fsyntax-only:%(invoke_as)}}}}", 0},
>     {"-",
>      "%{!E:%e-E required when input is from standard input}\
> --- 857,867 ----
>         %{!E:%{!M:%{!MM:\
>             %{traditional|ftraditional:\
>   %eGNU C no longer supports -traditional without -E}\
> ! 	  %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \
> ! 		%(cpp_options) %{save-temps:%b.i} %{!save-temps:%g.i} \n\
> ! 		    cc1 -fpreprocessed %{save-temps:%b.i} %{!save-temps:%g.i} %(cc1_options)}\
> ! 	  %{!save-temps:%{!traditional-cpp:%{!no-integrated-cpp:\
> ! 		cc1 %(cpp_unique_options) %(cc1_options)}}}\
>           %{!fsyntax-only:%(invoke_as)}}}}", 0},
>     {"-",
>      "%{!E:%e-E required when input is from standard input}\
> *************** static const struct option_map option_ma
> *** 965,970 ****
> --- 965,971 ----
>      {"--library-directory", "-L", "a"},
>      {"--machine", "-m", "aj"},
>      {"--machine-", "-m", "*j"},
> +    {"--no-integrated-cpp", "-no-integrated-cpp", 0},
>      {"--no-line-commands", "-P", 0},
>      {"--no-precompiled-includes", "-noprecomp", 0},
>      {"--no-standard-includes", "-nostdinc", 0},
>
>
>
>
>
>

Re: -no-integrated-cpp flag (patches for gcc3.3)

[Neil Booth]

Ashif S. Harji wrote:-

> 
> The patch passed bootstrap and testing.
> 
> Bootstrapping and Testing:
> 
> On i686-pc-linux-gnu:
>    - bootstrap was successful
>    - no changes in testsuite results when compared to original (gcc-20030224 snapshot)

OK, for completeness, here is what I've applied to 3.3 and 3.4.

Thanks,

Neil.

============================================================
Index: gcc/gcc.c
--- gcc/gcc.c	13 Dec 2002 00:17:19 -0000	1.350
+++ gcc/gcc.c	2 Mar 2003 10:08:53 -0000
@@ -857,11 +857,11 @@ static const struct compiler default_com
       %{!E:%{!M:%{!MM:\
           %{traditional|ftraditional:\
 %eGNU C no longer supports -traditional without -E}\
-	  %{save-temps|traditional-cpp:%(trad_capable_cpp) \
-		%(cpp_options) %b.i \n\
-		    cc1 -fpreprocessed %b.i %(cc1_options)}\
-	  %{!save-temps:%{!traditional-cpp:\
-		cc1 %(cpp_unique_options) %(cc1_options)}}\
+	  %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \
+		%(cpp_options) %{save-temps:%b.i} %{!save-temps:%g.i} \n\
+		    cc1 -fpreprocessed %{save-temps:%b.i} %{!save-temps:%g.i} %(cc1_options)}\
+	  %{!save-temps:%{!traditional-cpp:%{!no-integrated-cpp:\
+		cc1 %(cpp_unique_options) %(cc1_options)}}}\
         %{!fsyntax-only:%(invoke_as)}}}}", 0},
   {"-",
    "%{!E:%e-E required when input is from standard input}\
@@ -965,6 +965,7 @@ static const struct option_map option_ma
    {"--library-directory", "-L", "a"},
    {"--machine", "-m", "aj"},
    {"--machine-", "-m", "*j"},
+   {"--no-integrated-cpp", "-no-integrated-cpp", 0},
    {"--no-line-commands", "-P", 0},
    {"--no-precompiled-includes", "-noprecomp", 0},
    {"--no-standard-includes", "-nostdinc", 0},
============================================================
Index: gcc/cp/lang-specs.h
--- gcc/cp/lang-specs.h	10 Aug 2002 20:58:45 -0000	1.53
+++ gcc/cp/lang-specs.h	2 Mar 2003 10:08:53 -0000
@@ -36,10 +36,10 @@ Boston, MA 02111-1307, USA.  */
     "%{E|M|MM:cc1plus -E %{!no-gcc:-D__GNUG__=%v1}\
        %(cpp_options) %2 %(cpp_debug_options)}\
      %{!E:%{!M:%{!MM:\
-       %{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}}\
+       %{save-temps|no-integrated-cpp:cc1plus -E %{!no-gcc:-D__GNUG__=%v1}\
+		%(cpp_options) %2 %{save-temps:%b.ii} %{!save-temps:%g.ii} \n}\
+      cc1plus %{save-temps|no-integrated-cpp:-fpreprocessed %{save-temps:%b.ii} %{!save-temps:%g.ii}}\
+	      %{!save-temps:%{!no-integrated-cpp:%(cpp_unique_options) %{!no-gcc:-D__GNUG__=%v1}}}\
 	%(cc1_options) %2 %{+e1*}\
        %{!fsyntax-only:%(invoke_as)}}}}",
      CPLUSPLUS_CPP_SPEC},
============================================================
Index: gcc/doc/invoke.texi
--- gcc/doc/invoke.texi	23 Feb 2003 16:59:31 -0000	1.209.2.15
+++ gcc/doc/invoke.texi	2 Mar 2003 10:08:57 -0000
@@ -165,7 +165,7 @@ in the following sections.
 -ansi  -std=@var{standard}  -aux-info @var{filename} @gol
 -fno-asm  -fno-builtin -fno-builtin-@var{function} @gol
 -fhosted  -ffreestanding  -fms-extensions @gol
--trigraphs  -traditional  -traditional-cpp @gol
+-trigraphs  -no-integrated-cpp  -traditional  -traditional-cpp @gol
 -fallow-single-precision  -fcond-mismatch @gol
 -fsigned-bitfields  -fsigned-char @gol
 -funsigned-bitfields  -funsigned-char @gol
@@ -1184,6 +1184,17 @@ Accept some non-standard constructs used
 @opindex trigraphs
 Support ISO C trigraphs.  The @option{-ansi} option (and @option{-std}
 options for strict ISO C conformance) implies @option{-trigraphs}.
+
+@item -no-integrated-cpp
+@opindex no-integrated-cpp
+Performs a compilation in two passes: preprocessing and compiling.  This
+option allows a user supplied "cc1", "cc1plus", or "cc1obj" via the
+@option{-B} option. The user supplied compilation step can then add in
+an additional preprocessing step after normal preprocessing but before
+compiling. The default is to use the integrated cpp (internal cpp)
+
+The semantics of this option will change if "cc1", "cc1plus", and
+"cc1obj" are merged.
 
 @cindex traditional C language
 @cindex C language, traditional
============================================================
Index: gcc/objc/lang-specs.h
--- gcc/objc/lang-specs.h	10 Aug 2002 20:58:45 -0000	1.26
+++ gcc/objc/lang-specs.h	2 Mar 2003 10:08:57 -0000
@@ -30,10 +30,10 @@ Boston, MA 02111-1307, USA.  */
       %{!E:%{!M:%{!MM:\
 	%{traditional|ftraditional|traditional-cpp:\
 %eGNU Objective C no longer supports traditional compilation}\
-	%{save-temps:cc1obj -E %(cpp_options) %b.mi \n\
-	    cc1obj -fpreprocessed %b.mi %(cc1_options) %{gen-decls}}\
-	%{!save-temps:\
-	    cc1obj %(cpp_unique_options) %(cc1_options) %{gen-decls}}\
+	%{save-temps|no-integrated-cpp:cc1obj -E %(cpp_options) %{save-temps:%b.mi} %{!save-temps:%g.mi} \n\
+	    cc1obj -fpreprocessed %{save-temps:%b.mi} %{!save-temps:%g.mi} %(cc1_options) %{gen-decls}}\
+	%{!save-temps:%{!no-integrated-cpp:\
+	    cc1obj %(cpp_unique_options) %(cc1_options) %{gen-decls}}}\
         %{!fsyntax-only:%(invoke_as)}}}}", 0},
   {".mi", "@objc-cpp-output", 0},
   {"@objc-cpp-output",