[PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's
${EXTRA_OECONF}.  This is similar to what we have in the glibc recipe
files.

This allows for a tune file to add something like:

GCC_EXTRA_OECONF += "--with-cpu=e5500"

If needed.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 meta/recipes-devtools/gcc/gcc-4.6.inc              |    2 +-
 meta/recipes-devtools/gcc/gcc-configure-common.inc |    2 ++
 meta/recipes-devtools/gcc/gcc_4.5.1.bb             |    2 +-
 meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb    |    2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 4c1e1e1..b054266 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
 require gcc-common.inc
 
-PR = "r2"
+PR = "r3"
 
 # Third digit in PV should be incremented after a minor release
 # happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 9f5ba33..aac6d69 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -20,6 +20,7 @@ LANGUAGES ?= "c,c++${FORTRAN}${JAVA}"
 SPECIAL_ARCH_LIST = "powerpc"
 OPTSPACE = ${@base_contains("SPECIAL_ARCH_LIST", "${TARGET_ARCH}", "", "--enable-target-optspace",d)}
 
+GCC_EXTRA_OECONF ?= ""
 EXTRA_OECONF_BASE ?= ""
 EXTRA_OECONF_PATHS ?= ""
 EXTRA_OECONF_INITIAL ?= ""
@@ -39,6 +40,7 @@ EXTRA_OECONF = "${@['--enable-clocale=generic', ''][bb.data.getVar('USE_NLS', d,
                 --enable-libstdcxx-pch \
                 --program-prefix=${TARGET_PREFIX} \
                 ${OPTSPACE} \
+                ${GCC_EXTRA_OECONF} \
                 ${EXTRA_OECONF_BASE} \
                 ${EXTRA_OECONF_FPU} \
                 ${EXTRA_OECONF_PATHS} \
diff --git a/meta/recipes-devtools/gcc/gcc_4.5.1.bb b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
index 12e42c4..f036cb1 100644
--- a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
@@ -1,4 +1,4 @@
-PR = "r7"
+PR = "r8"
 require gcc-${PV}.inc
 require gcc-configure-target.inc
 require gcc-package-target.inc
diff --git a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
index 2df12ef..9fd2b0a 100644
--- a/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
+++ b/meta/recipes-devtools/gcc/gcc_csl-arm-2008q1.bb
@@ -1,4 +1,4 @@
-PR = "r4"
+PR = "r5"
 
 require gcc-${PV}.inc
 require gcc-configure-target.inc
-- 
1.7.3.4

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Phil Blundell]

On Mon, 2011-08-01 at 09:21 -0500, Kumar Gala wrote:
> Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's
> ${EXTRA_OECONF}.  This is similar to what we have in the glibc recipe
> files.
> 
> This allows for a tune file to add something like:
> 
> GCC_EXTRA_OECONF += "--with-cpu=e5500"
> 
> If needed.
> 
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Why is that desirable?  From the looks of that patch it will affect
gcc-cross as well as target gcc and, if you're going to do this, I think
you need to find some way to disambiguate the resulting compilers.
Otherwise there is going to be no way to predict what options ${CC} was
built with.  

Even for the on-target gcc case, if you are going to start putting
MACHINE-specific variables into the configure commandline then you need
to make sure that the output packages have an appropriate Architecture.
I don't think that's going to be the case at the moment.

p.

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

On Aug 1, 2011, at 9:30 AM, Phil Blundell wrote:

> On Mon, 2011-08-01 at 09:21 -0500, Kumar Gala wrote:
>> Added a ${GCC_EXTRA_OECONF} to the the building up of gcc's
>> ${EXTRA_OECONF}.  This is similar to what we have in the glibc recipe
>> files.
>> 
>> This allows for a tune file to add something like:
>> 
>> GCC_EXTRA_OECONF += "--with-cpu=e5500"
>> 
>> If needed.
>> 
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> 
> Why is that desirable?  From the looks of that patch it will affect
> gcc-cross as well as target gcc and, if you're going to do this, I think
> you need to find some way to disambiguate the resulting compilers.
> Otherwise there is going to be no way to predict what options ${CC} was
> built with.

Its desirable to get a consistent set of tools.  For example it means the cross toolchain in an ADT will target the given processor it was built with w/o having to explicit set flags to gcc.

Additionally, it might be useful for building multilib gcc on powerpc that seems to need --with-cpu-32 --with-cpu-64.

Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:

ppc64e5500-poky-linux-gcc

> Even for the on-target gcc case, if you are going to start putting
> MACHINE-specific variables into the configure commandline then you need
> to make sure that the output packages have an appropriate Architecture.
> I don't think that's going to be the case at the moment.

I'm open to solutions to my problem, but need to find someway to pass '--with-cpu=' to configure.

- k

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Phil Blundell]

On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:

The thing about disambiguating was that, if you're going to modify the
configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
to consider what happens if you have a single build directory that's
being used for multiple MACHINEs.

From what you've described as the usecase for this feature it sounds as
though the easiest answer to that is simply to stop your extra flags
from being used by gcc-cross and ensure that they're only used by gcc.
Then you'd just need to make sure that the PACKAGE_ARCH for gcc always
reflects the options being used, which sounds lke it might already be
true for ppc but possibly is not in general.  (The target gcc package
isn't buildable for me at the moment but a bit of poking around with
bitbake -e suggests that it's just getting the generic architecture
PACKAGE_ARCH on i586 at least.)

I'm not familiar enough with the sdk code to know whether there are
going to be any issues around that or not.

p.

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Tom Rini]

On 08/01/2011 09:07 AM, Phil Blundell wrote:
> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> 
> The thing about disambiguating was that, if you're going to modify the
> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> to consider what happens if you have a single build directory that's
> being used for multiple MACHINEs.

What, I think, Kumar is driving at is why are you saying MACHINE when
it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie]

On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> > 
> > The thing about disambiguating was that, if you're going to modify the
> > configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> > to consider what happens if you have a single build directory that's
> > being used for multiple MACHINEs.
> 
> What, I think, Kumar is driving at is why are you saying MACHINE when
> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500

The question is whether we'd like to get to the point of having more
toolchains or less toolchains. I'd personally like to get to the point
of less toolchains (e.g. one per arch) rather than more of them. We
already pass all the appropriate flags around in the ADT/sdk code and in
our own cross builds, we could easily add those to the default target
environment too. This would actually make it clearer what is going on to
the end user too rather than hiding the details into the gcc
compilation.

So all things considered, I don't think this is the best way to go...


Cheers,

Richard

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:

> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
>>> 
>>> The thing about disambiguating was that, if you're going to modify the
>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
>>> to consider what happens if you have a single build directory that's
>>> being used for multiple MACHINEs.
>> 
>> What, I think, Kumar is driving at is why are you saying MACHINE when
>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
> 
> The question is whether we'd like to get to the point of having more
> toolchains or less toolchains. I'd personally like to get to the point
> of less toolchains (e.g. one per arch) rather than more of them. We
> already pass all the appropriate flags around in the ADT/sdk code and in
> our own cross builds, we could easily add those to the default target
> environment too. This would actually make it clearer what is going on to
> the end user too rather than hiding the details into the gcc
> compilation.
> 
> So all things considered, I don't think this is the best way to go...
> 

How is this done or exported to the user of an ADT/sdk toolchain?

- k

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie]

On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> 
> > On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> >>> 
> >>> The thing about disambiguating was that, if you're going to modify the
> >>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> >>> to consider what happens if you have a single build directory that's
> >>> being used for multiple MACHINEs.
> >> 
> >> What, I think, Kumar is driving at is why are you saying MACHINE when
> >> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
> > 
> > The question is whether we'd like to get to the point of having more
> > toolchains or less toolchains. I'd personally like to get to the point
> > of less toolchains (e.g. one per arch) rather than more of them. We
> > already pass all the appropriate flags around in the ADT/sdk code and in
> > our own cross builds, we could easily add those to the default target
> > environment too. This would actually make it clearer what is going on to
> > the end user too rather than hiding the details into the gcc
> > compilation.
> > 
> > So all things considered, I don't think this is the best way to go...
> > 
> 
> How is this done or exported to the user of an ADT/sdk toolchain?

There is a script included in the toolchain tarball which contains the
appropriate information. I don't have one handy to check but I suspect
Jessica will have. Jessica?

Cheers,

Richard

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote:

> On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
>> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
>> 
>>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
>>>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
>>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
>>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
>>>>> 
>>>>> The thing about disambiguating was that, if you're going to modify the
>>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
>>>>> to consider what happens if you have a single build directory that's
>>>>> being used for multiple MACHINEs.
>>>> 
>>>> What, I think, Kumar is driving at is why are you saying MACHINE when
>>>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
>>> 
>>> The question is whether we'd like to get to the point of having more
>>> toolchains or less toolchains. I'd personally like to get to the point
>>> of less toolchains (e.g. one per arch) rather than more of them. We
>>> already pass all the appropriate flags around in the ADT/sdk code and in
>>> our own cross builds, we could easily add those to the default target
>>> environment too. This would actually make it clearer what is going on to
>>> the end user too rather than hiding the details into the gcc
>>> compilation.
>>> 
>>> So all things considered, I don't think this is the best way to go...
>>> 
>> 
>> How is this done or exported to the user of an ADT/sdk toolchain?
> 
> There is a script included in the toolchain tarball which contains the
> appropriate information. I don't have one handy to check but I suspect
> Jessica will have. Jessica?
> 

Ping on this script?

- k

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie]

On Mon, 2011-08-08 at 11:32 -0500, Kumar Gala wrote:
> On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote:
> 
> > On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
> >> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> >> 
> >>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >>>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> >>>>> 
> >>>>> The thing about disambiguating was that, if you're going to modify the
> >>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> >>>>> to consider what happens if you have a single build directory that's
> >>>>> being used for multiple MACHINEs.
> >>>> 
> >>>> What, I think, Kumar is driving at is why are you saying MACHINE when
> >>>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
> >>> 
> >>> The question is whether we'd like to get to the point of having more
> >>> toolchains or less toolchains. I'd personally like to get to the point
> >>> of less toolchains (e.g. one per arch) rather than more of them. We
> >>> already pass all the appropriate flags around in the ADT/sdk code and in
> >>> our own cross builds, we could easily add those to the default target
> >>> environment too. This would actually make it clearer what is going on to
> >>> the end user too rather than hiding the details into the gcc
> >>> compilation.
> >>> 
> >>> So all things considered, I don't think this is the best way to go...
> >>> 
> >> 
> >> How is this done or exported to the user of an ADT/sdk toolchain?
> > 
> > There is a script included in the toolchain tarball which contains the
> > appropriate information. I don't have one handy to check but I suspect
> > Jessica will have. Jessica?
> > 
> 
> Ping on this script?

I have a build handy so here is the 32 bit toolchain which runs on 64
bit systems for x86:

$ cat environment-setup-i586-poky-linux 
export PATH=/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH
export PKG_CONFIG_SYSROOT_DIR=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux
export PKG_CONFIG_PATH=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux/usr/lib/pkgconfig
export CONFIG_SITE=/opt/poky/1.0+snapshot/site-config-i586-poky-linux
export CC=i586-poky-linux-gcc
export CXX=i586-poky-linux-g++
export GDB=i586-poky-linux-gdb
export TARGET_PREFIX=i586-poky-linux-
export CONFIGURE_FLAGS="--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CFLAGS=" -m32  -march=i586 --sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CXXFLAGS=" -m32  -march=i586 --sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export LDFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CPPFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export OECORE_NATIVE_SYSROOT="/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export OECORE_ACLOCAL_OPTS="-I /opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export POKY_DISTRO_VERSION="1.0+snapshot-20110802"

You can see it captures the correct CFLAGS etc.

Cheers,

Richard

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote:

> 
> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> 
>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
>>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
>>>> 
>>>> The thing about disambiguating was that, if you're going to modify the
>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
>>>> to consider what happens if you have a single build directory that's
>>>> being used for multiple MACHINEs.
>>> 
>>> What, I think, Kumar is driving at is why are you saying MACHINE when
>>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
>> 
>> The question is whether we'd like to get to the point of having more
>> toolchains or less toolchains. I'd personally like to get to the point
>> of less toolchains (e.g. one per arch) rather than more of them. We
>> already pass all the appropriate flags around in the ADT/sdk code and in
>> our own cross builds, we could easily add those to the default target
>> environment too. This would actually make it clearer what is going on to
>> the end user too rather than hiding the details into the gcc
>> compilation.
>> 
>> So all things considered, I don't think this is the best way to go...
>> 
> 
> How is this done or exported to the user of an ADT/sdk toolchain?

I still dont understand the concern here.  GCC is already picking a default for -mcpu, so why is having a tune file pick a better default any issue?

If there is an explicit -mcpu or other options like -mtune, the setting of --with-cpu will get ignored.

- k

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie]

On Mon, 2011-08-08 at 11:35 -0500, Kumar Gala wrote:
> On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote:
> 
> > 
> > On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> > 
> >> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> >>>> 
> >>>> The thing about disambiguating was that, if you're going to modify the
> >>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> >>>> to consider what happens if you have a single build directory that's
> >>>> being used for multiple MACHINEs.
> >>> 
> >>> What, I think, Kumar is driving at is why are you saying MACHINE when
> >>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
> >> 
> >> The question is whether we'd like to get to the point of having more
> >> toolchains or less toolchains. I'd personally like to get to the point
> >> of less toolchains (e.g. one per arch) rather than more of them. We
> >> already pass all the appropriate flags around in the ADT/sdk code and in
> >> our own cross builds, we could easily add those to the default target
> >> environment too. This would actually make it clearer what is going on to
> >> the end user too rather than hiding the details into the gcc
> >> compilation.
> >> 
> >> So all things considered, I don't think this is the best way to go...
> >> 
> > 
> > How is this done or exported to the user of an ADT/sdk toolchain?
> 
> I still dont understand the concern here.  GCC is already picking a
> default for -mcpu, so why is having a tune file pick a better default
> any issue?
> 
> If there is an explicit -mcpu or other options like -mtune, the
> setting of --with-cpu will get ignored.

There are two sides to this:

a) In the ppc case there isn't that much of an issue since the different
tunes tend to have their own very specific package architectures. It
likely therefore doesn't matter much if gcc is hardcoded to a given
default. It would matter more on certain arm combinations I can think of
depending on what got hardcoded as default.

b) There are very few circumstances you'd ever be in an environment
where the correct cpu flags weren't getting supplied (and we have sanity
checks to ensure they do). We want to be heading to wards less
toolchains, not more toolchains and the more we code into the toolchain,
the more different toolchain builds we'll need.

Whilst I can see the reason for wanting a), I worry it will mask issues
where the flags are missing and also cause more toolchain fragmentation
with people very likely to get the values wrong in the arm case. I'm
therefore reluctant.

Cheers,

Richard

Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Phil Blundell]

On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> > On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
> > 
> > The thing about disambiguating was that, if you're going to modify the
> > configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> > to consider what happens if you have a single build directory that's
> > being used for multiple MACHINEs.
> 
> What, I think, Kumar is driving at is why are you saying MACHINE when
> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500

I said MACHINE because, in general, it's the MACHINE which selects the
tune.  If it's the case that (for powerpc at least) all the tunes end up
setting a distinct PACKAGE_ARCH then this probably is a non-issue there,
but that isn't true in the general case.  (For example, the arm926ejs
tune file sets PACKAGE_ARCH=armv5te or something, so it wouldn't be
sensible for it to be configuring gcc --with-cpu=arm926ej-s.)

Likewise for gcc-cross, if you're going to let this apply there then you
need to make sure that the TARGET_ARCH value in the triplet is at least
as specific as the tuning you ask for, otherwise you will end up with
multiple different compilers all called armv5te-oe-linux-gcc or
whatever.

p.