Fix redundant usage of -mcpu and -march/-mtune

Disable adding -mtune or -march to the external toolchain parameters if -mcpu is present.

Signed-off-by Karoly Kasza <[email protected]>

---
 toolchain/toolchain-external/toolchain-external.mk |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Dear Karoly Kasza,

Quoted 7 lines · Karoly Kasza

Disable adding -mtune or -march to the external toolchain parameters if -mcpu is present.

Signed-off-by Karoly Kasza <[email protected]>

---
 toolchain/toolchain-external/toolchain-external.mk |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

We discussed this patch at the last Buildroot meeting, and our feeling is that it's not the correct approach. I've since then sent a patch series that fix the same problem. Our approach is:

* On ARM, to no longer specify -march, but only -mcpu, since the latter is used by gcc to deduce the former.

* In general, get rid of -mtune, since it doesn't make much sense in the context of Buildroot where we target one specific system, and therefore using -mcpu is sufficient.

So, we've marked your patch as Rejected in our patch tracking system.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

I've been using the Linaro external toolchain in the latest GIT to generate ARM code. I've found that when using this external compiler, Buildroot compulsorily specifies the -mcpu and -march switches to GCC, which is redundant (-march and -mtune can be concluded from -mcpu, see
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html )
While most of the time this only generates a warning, mmc-utils can not be compiled this way and probably other packages suffer from this as well.

I recommend altering toolchain/toolchain-external/toolchain-external.mk, so it won't supply redundant GCC switches.

Dear Karoly Kasza,

Thanks for your report!

Quoted 1 line · Karoly Kasza

I've been using the Linaro external toolchain in the latest GIT to

generate ARM

Quoted 2 lines

code. I've found that when using this external compiler, Buildroot compulsorily specifies the -mcpu and -march switches to GCC, which is

redundant

Quoted 3 lines

(-march and -mtune can be concluded from -mcpu, see
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html )
While most of the time this only generates a warning, mmc-utils can not

be

Quoted 1 line

compiled this way and probably other packages suffer from this as well.

Which mmc-utils problem have you seen? I've just tried building the following configuration:

BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_EABIHF=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_MMC_UTILS=y

And it just built fine, and uses a Linaro toolchain.

I recommend altering toolchain/toolchain-external/toolchain-external.mk,

Quoted 1 line

so it won't supply redundant GCC switches.

The potential problem I see is that the code you're changing is used for *all* architectures, but the change you're making has only been made with ARM specificities in mind. Does ignoring -march and -mtune when -mcpu is defined also works for all other architectures?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

The BR2_cortex_a7=y breaks it, it will generate a warning while compiling busybox (every invocation of gcc):
warning: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [enabled by default]

Then an error with mmc-utils like this:
mmc.c:1:0: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

Quoted 5 lines

The potential problem I see is that the code you're changing is used for *all* architectures, but the change you're making has only been made with ARM specificities in mind. Does ignoring -march and -mtune when -mcpu is defined also works for all other architectures?

This is a tough question, because based on the GCC online manual, not all architectures accept all three parameters.
It looks like -mcpu is always the most definite, but is is deprecated on i386 and x86_64 for example.

Maybe it would be wise to define and use these 3 parameters only based on the target architecture.

Dear K?roly Kasza,

Quoted 8 lines · K?roly Kasza

The BR2_cortex_a7=y breaks it, it will generate a warning while compiling busybox (every invocation of gcc):
warning: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [enabled by default]

Then an error with mmc-utils like this:
mmc.c:1:0: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

Indeed, with Cortex-A7, I can reproduce this. This is because Cortex-A7, A-12 and A-15 support more features than the other armv7-a cores (A5, A8, A9), so gcc has a separate -march argument: armv7ve.

So normally, we should set BR2_GCC_TARGET_ARCH to armv7ve for those Cortex-A variants. I'm currently experimenting with this, but I'm having a few issues. Also, it's likely that armv7ve is quite recent, and may not be present in older gcc versions.

Quoted 10 lines

Quoted 5 lines

The potential problem I see is that the code you're changing is used for *all* architectures, but the change you're making has only been made with ARM specificities in mind. Does ignoring -march and -mtune when -mcpu is defined also works for all other architectures?

This is a tough question, because based on the GCC online manual, not all architectures accept all three parameters.
It looks like -mcpu is always the most definite, but is is deprecated on i386 and x86_64 for example.

Quoted 2 lines

Maybe it would be wise to define and use these 3 parameters only based on the target architecture.

This is already the case. They are only passed if BR2_GCC_TARGET_{ARCH,CPU,TUNE} are defined. Some architectures (such as ARM) defines all three, but other architectures (such as x86) do not.

Now I see. In this case, maybe the simplest would be to just leave

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Quoted 6 lines

So normally, we should set BR2_GCC_TARGET_ARCH to armv7ve for those Cortex-A variants. I'm currently experimenting with this, but I'm having a few issues. Also, it's likely that armv7ve is quite recent, and may not be present in older gcc versions.

That's the case with the Linaro 2014.02 toolchain - in GCC 4.8.2 the armv7ve does not exist
(http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ARM-Options.html#ARM-Options).

Quoted 4 lines

This is already the case. They are only passed if BR2_GCC_TARGET_{ARCH,CPU,TUNE} are defined. Some architectures (such as ARM) defines all three, but other architectures (such as x86) do not.

Now I see. In this case, maybe the simplest would be to just leave BR2_GCC_TARGET_ARCH
undefined in arch/Config.in.arm if the user selected a proper CPU (and not just some generic one).

Also, based on the documentation it should be completely unnecessary to define -march if we have the accurate CPU with -mcpu (on ARM at least).

Dear K?roly Kasza,

Quoted 4 lines · K?roly Kasza

Quoted 1 line

That's the case with the Linaro 2014.02 toolchain - in GCC 4.8.2 the armv7ve does not exist
(

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ARM-Options.html#ARM-Options).

Yeah, in gcc 4.8.2 vanilla. But Linaro toolchains don't use a vanilla gcc, they have lots of ARM related patches. And if the Linaro toolchains complains that -march=armv7-a is incompatible with -mcpu=cortex-a7, then quite certainly it means that cortex-a7 is part of a different -march family, according to this toolchain.

Quoted 7 lines

This is already the case. They are only passed if

Quoted 3 lines

BR2_GCC_TARGET_{ARCH,CPU,TUNE} are defined. Some architectures (such as ARM) defines all three, but other architectures (such as x86) do not.

Now I see. In this case, maybe the simplest would be to just leave BR2_GCC_TARGET_ARCH
undefined in arch/Config.in.arm if the user selected a proper CPU (and

not

Quoted 1 line

just some generic one).

Not sure what you mean by "not just some generic one". In the menuconfig, what we ask the user is to define the specific ARM core being used. From that we can derive the -march and -mcpu values. But indeed, the -march value is quite useless.

Dear K?roly Kasza,

Quoted 9 lines · K?roly Kasza

Quoted 6 lines

So normally, we should set BR2_GCC_TARGET_ARCH to armv7ve for those Cortex-A variants. I'm currently experimenting with this, but I'm having a few issues. Also, it's likely that armv7ve is quite recent, and may not be present in older gcc versions.

That's the case with the Linaro 2014.02 toolchain - in GCC 4.8.2 the armv7ve does not exist
(

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/ARM-Options.html#ARM-Options).

Yeah, in gcc 4.8.2 vanilla. But Linaro toolchains don't use a vanilla gcc, they have lots of ARM related patches. And if the Linaro toolchains complains that -march=armv7-a is incompatible with -mcpu=cortex-a7, then quite certainly it means that cortex-a7 is part of a different -march family, according to this toolchain.

Quoted 7 lines

Quoted 4 lines

This is already the case. They are only passed if BR2_GCC_TARGET_{ARCH,CPU,TUNE} are defined. Some architectures (such as ARM) defines all three, but other architectures (such as x86) do not.

Now I see. In this case, maybe the simplest would be to just leave BR2_GCC_TARGET_ARCH
undefined in arch/Config.in.arm if the user selected a proper CPU (and

not

Quoted 1 line

just some generic one).

Not sure what you mean by "not just some generic one". In the menuconfig, what we ask the user is to define the specific ARM core being used. From that we can derive the -march and -mcpu values. But indeed, the -march value is quite useless.

However, I believe there are place in Buildroot where we do use the BR2_GCC_TARGET_ARCH value for other things than just the compiler flags. We would have to audit those before removing BR2_GCC_TARGET_ARCH from Config.in.arm.

Quoted 2 lines

Also, based on the documentation it should be completely unnecessary to define -march if we have the accurate CPU with -mcpu (on ARM at least).

Correct.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com