[Buildroot] [git commit] arch/x86: get rid of BR2_GCC_TARGET_TUNE

[Buildroot] [git commit] arch/x86: get rid of BR2_GCC_TARGET_TUNE

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=6bec1d5191a2f017f1e7aa46286de50ba067b7de
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

According to the gcc documentation, -march implies -mtune on x86, so
defining both BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE is
redundant. Therefore, this commit removes the definition of
BR2_GCC_TARGET_TUNE on x86.

However, while doing so, it adds one new case for BR2_GCC_TARGET_ARCH:
using -march=generic when BR2_x86_generic is selected.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 arch/Config.in.x86 |   32 +-------------------------------
 1 files changed, 1 insertions(+), 31 deletions(-)

diff --git a/arch/Config.in.x86 b/arch/Config.in.x86
index 9aa4ea2..0b7919b 100644
--- a/arch/Config.in.x86
+++ b/arch/Config.in.x86
@@ -205,37 +205,6 @@ config BR2_ENDIAN
 config BR2_ARCH_HAS_ATOMICS
 	default y if !BR2_x86_i386
 
-config BR2_GCC_TARGET_TUNE
-	default "i386"		if BR2_x86_i386
-	default "i486"		if BR2_x86_i486
-	default "i586"		if BR2_x86_i586
-	default "pentium-mmx"	if BR2_x86_pentium_mmx
-	default "i686"		if BR2_x86_i686
-	default "pentiumpro"	if BR2_x86_pentiumpro
-	default "pentium-m"	if BR2_x86_pentium_m
-	default "pentium2"	if BR2_x86_pentium2
-	default "pentium3"	if BR2_x86_pentium3
-	default "pentium4"	if BR2_x86_pentium4
-	default "prescott"	if BR2_x86_prescott
-	default "nocona"	if BR2_x86_nocona
-	default "core2"		if BR2_x86_core2
-	default "corei7"	if BR2_x86_corei7
-	default "atom"		if BR2_x86_atom
-	default "k8"		if BR2_x86_opteron
-	default "k8-sse3"	if BR2_x86_opteron_sse3
-	default "barcelona"	if BR2_x86_barcelona
-	default "btver2"	if BR2_x86_jaguar
-	default "k6"		if BR2_x86_k6
-	default "k6-2"		if BR2_x86_k6_2
-	default "athlon"	if BR2_x86_athlon
-	default "athlon-4"	if BR2_x86_athlon_4
-	default "winchip-c6"	if BR2_x86_winchip_c6
-	default "winchip2"	if BR2_x86_winchip2
-	default "c3"		if BR2_x86_c3
-	default "c3-2"		if BR2_x86_c32
-	default "geode"		if BR2_x86_geode
-	default "generic"	if BR2_x86_generic
-
 config BR2_GCC_TARGET_ARCH
 	default "i386"		if BR2_x86_i386
 	default "i486"		if BR2_x86_i486
@@ -265,3 +234,4 @@ config BR2_GCC_TARGET_ARCH
 	default "c3"		if BR2_x86_c3
 	default "c3-2"		if BR2_x86_c32
 	default "geode"		if BR2_x86_geode
+	default "generic"	if BR2_x86_generic

[Buildroot] [git commit] arch/x86: get rid of BR2_GCC_TARGET_TUNE

[Károly Kasza]

Hello all,

since this commit, GCC fails to build at the initial stage, with the i386
or x86_x64 targets, if BR2_GCC_TARGET_ARCH is set to "generic".

4.8 error message:
configure: error: cannot compute suffix of object files: cannot compile
4.9 error message:
Unknown CPU given in --with-arch=generic.

I would substitute the "generic" variable with "" in arch/Config.in.x86,
which would omit
HOST_GCC_COMMON_CONF_OPTS += --with-arch=$(BR2_GCC_TARGET_ARCH)
in package/gcc/gcc.mk. That makes compiling gcc possible.
But that would also mean CC_TARGET_ARCH would also be blank in
toolchain-external.mk, omitting
TOOLCHAIN_EXTERNAL_CFLAGS += -march=$(CC_TARGET_ARCH_).

I guess omitting a parameter, or setting it to "generic" _should_ mean the
same, but I'm not sure.

Best regards
Karoly

On Fri, Nov 7, 2014 at 12:09 AM, Peter Korsgaard <peter@korsgaard.com>
wrote:

> commit:
> http://git.buildroot.net/buildroot/commit/?id=6bec1d5191a2f017f1e7aa46286de50ba067b7de
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>
> According to the gcc documentation, -march implies -mtune on x86, so
> defining both BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE is
> redundant. Therefore, this commit removes the definition of
> BR2_GCC_TARGET_TUNE on x86.
>
> However, while doing so, it adds one new case for BR2_GCC_TARGET_ARCH:
> using -march=generic when BR2_x86_generic is selected.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
> ---
>  arch/Config.in.x86 |   32 +-------------------------------
>  1 files changed, 1 insertions(+), 31 deletions(-)
>
> diff --git a/arch/Config.in.x86 b/arch/Config.in.x86
> index 9aa4ea2..0b7919b 100644
> --- a/arch/Config.in.x86
> +++ b/arch/Config.in.x86
> @@ -205,37 +205,6 @@ config BR2_ENDIAN
>  config BR2_ARCH_HAS_ATOMICS
>         default y if !BR2_x86_i386
>
> -config BR2_GCC_TARGET_TUNE
> -       default "i386"          if BR2_x86_i386
> -       default "i486"          if BR2_x86_i486
> -       default "i586"          if BR2_x86_i586
> -       default "pentium-mmx"   if BR2_x86_pentium_mmx
> -       default "i686"          if BR2_x86_i686
> -       default "pentiumpro"    if BR2_x86_pentiumpro
> -       default "pentium-m"     if BR2_x86_pentium_m
> -       default "pentium2"      if BR2_x86_pentium2
> -       default "pentium3"      if BR2_x86_pentium3
> -       default "pentium4"      if BR2_x86_pentium4
> -       default "prescott"      if BR2_x86_prescott
> -       default "nocona"        if BR2_x86_nocona
> -       default "core2"         if BR2_x86_core2
> -       default "corei7"        if BR2_x86_corei7
> -       default "atom"          if BR2_x86_atom
> -       default "k8"            if BR2_x86_opteron
> -       default "k8-sse3"       if BR2_x86_opteron_sse3
> -       default "barcelona"     if BR2_x86_barcelona
> -       default "btver2"        if BR2_x86_jaguar
> -       default "k6"            if BR2_x86_k6
> -       default "k6-2"          if BR2_x86_k6_2
> -       default "athlon"        if BR2_x86_athlon
> -       default "athlon-4"      if BR2_x86_athlon_4
> -       default "winchip-c6"    if BR2_x86_winchip_c6
> -       default "winchip2"      if BR2_x86_winchip2
> -       default "c3"            if BR2_x86_c3
> -       default "c3-2"          if BR2_x86_c32
> -       default "geode"         if BR2_x86_geode
> -       default "generic"       if BR2_x86_generic
> -
>  config BR2_GCC_TARGET_ARCH
>         default "i386"          if BR2_x86_i386
>         default "i486"          if BR2_x86_i486
> @@ -265,3 +234,4 @@ config BR2_GCC_TARGET_ARCH
>         default "c3"            if BR2_x86_c3
>         default "c3-2"          if BR2_x86_c32
>         default "geode"         if BR2_x86_geode
> +       default "generic"       if BR2_x86_generic
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>



-- 

?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141107/d22f836b/attachment.html>

[Buildroot] [git commit] arch/x86: get rid of BR2_GCC_TARGET_TUNE

[Peter Korsgaard]

>>>>> "K?roly" == K?roly Kasza <kaszak@gmail.com> writes:

 > Hello all,
 > since this commit, GCC fails to build at the initial stage, with the i386 or
 > x86_x64 targets, if BR2_GCC_TARGET_ARCH is set to "generic".

 > 4.8 error message:
 > configure: error: cannot compute suffix of object files: cannot compile
 > 4.9 error message:
 > Unknown CPU given in --with-arch=generic.

 > I would substitute the "generic" variable with "" in arch/Config.in.x86, which
 > would?omit
 > HOST_GCC_COMMON_CONF_OPTS += --with-arch=$(BR2_GCC_TARGET_ARCH)
 > in package/gcc/gcc.mk. That makes compiling gcc possible.
 > But that would also mean CC_TARGET_ARCH would also be blank in
 > toolchain-external.mk, omitting
 > TOOLCHAIN_EXTERNAL_CFLAGS += -march=$(CC_TARGET_ARCH_).

 > I guess omitting a parameter, or setting it to "generic" _should_ mean the
 > same, but I'm not sure.

It looks like you are right. From
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options:

-mtune=cpu-type
    Tune to cpu-type everything applicable about the generated code,
    except for the ABI and the set of available instructions. While
    picking a specific cpu-type schedules things appropriately for that
    particular chip, the compiler does not generate any code that cannot
    run on the default machine type unless you use a -march=cpu-type
    option. For example, if GCC is configured for i686-pc-linux-gnu then
    -mtune=pentium4 generates code that is tuned for Pentium 4 but still
    runs on i686 machines.

    The choices for cpu-type are the same as for -march. In addition,
    -mtune supports 2 extra choices for cpu-type:

    ?generic?
        Produce code optimized for the most common IA32/AMD64/EM64T
        processors. If you know the CPU on which your code will run,
        then you should use the corresponding -mtune or -march option
        instead of -mtune=generic. But, if you do not know exactly what
        CPU users of your application will have, then you should use
        this option.

        As new processors are deployed in the marketplace, the behavior
        of this option will change. Therefore, if you upgrade to a newer
        version of GCC, code generation controlled by this option will
        change to reflect the processors that are most common at the
        time that version of GCC is released.

        There is no -march=generic option because -march indicates the
        instruction set the compiler can use, and there is no generic
        instruction set applicable to all processors. In contrast,
        -mtune indicates the processor (or, in this case, collection of
        processors) for which the code is optimized.

So we shouldn't pass -march=generic. I'm not sure it even makes sense to
have the BR2_x86_generic option.

Thomas, Yann - Any comments?

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [git commit] arch/x86: get rid of BR2_GCC_TARGET_TUNE

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Fri, 07 Nov 2014 17:33:35 +0100, Peter Korsgaard wrote:

> It looks like you are right. From
> https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options:
> 
> -mtune=cpu-type
>     Tune to cpu-type everything applicable about the generated code,
>     except for the ABI and the set of available instructions. While
>     picking a specific cpu-type schedules things appropriately for that
>     particular chip, the compiler does not generate any code that cannot
>     run on the default machine type unless you use a -march=cpu-type
>     option. For example, if GCC is configured for i686-pc-linux-gnu then
>     -mtune=pentium4 generates code that is tuned for Pentium 4 but still
>     runs on i686 machines.
> 
>     The choices for cpu-type are the same as for -march. In addition,
>     -mtune supports 2 extra choices for cpu-type:
> 
>     ?generic?
>         Produce code optimized for the most common IA32/AMD64/EM64T
>         processors. If you know the CPU on which your code will run,
>         then you should use the corresponding -mtune or -march option
>         instead of -mtune=generic. But, if you do not know exactly what
>         CPU users of your application will have, then you should use
>         this option.
> 
>         As new processors are deployed in the marketplace, the behavior
>         of this option will change. Therefore, if you upgrade to a newer
>         version of GCC, code generation controlled by this option will
>         change to reflect the processors that are most common at the
>         time that version of GCC is released.
> 
>         There is no -march=generic option because -march indicates the
>         instruction set the compiler can use, and there is no generic
>         instruction set applicable to all processors. In contrast,
>         -mtune indicates the processor (or, in this case, collection of
>         processors) for which the code is optimized.
> 
> So we shouldn't pass -march=generic. I'm not sure it even makes sense to
> have the BR2_x86_generic option.
> 
> Thomas, Yann - Any comments?

As you suggest, I think the BR2_x86_generic option doesn't make any
sense, and we should simply get rid of it.

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