> Allowing the same option to behave differently in the driver and in cc1
> regarding whether it takes operands seems like error-prone complexity;
> every piece of code that now or in the future looks at CL_SEPARATE will
> need also to check whether it is in the driver or in cc1. Why is this
> cod
On Fri, 13 Aug 2010, Arnaud Charlet wrote:
> > The options passed to internal binaries such as cc1 are not a documented
> > public interface to GCC, so if you pass such options via -Wp you must
> > expect to need to change your makefiles when the GCC-internal interfaces
> > change. Instead, you s
> > I hit the following problem when trying to build a ppc64 Linux kernel
> > from svn today:
> >
> > # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes
> > -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> > scripts/basic/fixdep scripts/basic/fixdep.c
>
> The options passed to inte
On Fri, 13 Aug 2010, Anton Blanchard wrote:
> Hi Joseph,
>
> I hit the following problem when trying to build a ppc64 Linux kernel
> from svn today:
>
> # gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes
> -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep
> scr
Hi Joseph,
I hit the following problem when trying to build a ppc64 Linux kernel
from svn today:
# gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes
-Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep
scripts/basic/fixdep.c
cc1: error: unrecognized command line o
