[01/12] tune/arm: Set -mtune instead of -mcpu

Message ID	635c8757bf852c8a4248009f241c19146431cacd.1528320772.git.raj.khem@gmail.com
State	New
Headers	show Delivered-To: patch@linaro.org Received-SPF: pass (google.com: best guess record for domain of openembedded-core-bounces@lists.openembedded.org designates 140.211.169.62 as permitted sender) client-ip=140.211.169.62; From: Khem Raj <raj.khem@gmail.com> To: openembedded-core@lists.openembedded.org Date: Wed, 6 Jun 2018 14:37:17 -0700 Message-Id: <635c8757bf852c8a4248009f241c19146431cacd.1528320772.git.raj.khem@gmail.com> In-Reply-To: <cover.1528320772.git.raj.khem@gmail.com> References: <cover.1528320772.git.raj.khem@gmail.com> Subject: [OE-core] [PATCH 01/12] tune/arm: Set -mtune instead of -mcpu Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: openembedded-core-bounces@lists.openembedded.org Errors-To: openembedded-core-bounces@lists.openembedded.org
Series	Add GCC 8 recipes \| expand [V2,00/12] Add GCC 8 recipes [01/12] tune/arm: Set -mtune instead of -mcpu [02/12] valgrind: Remove code to remove -mcpu option on arm [03/12] tune-mips-74k.inc: add tune file for 74kc mips [04/12] gcc-8: Add recipes for 8.1 release [05/12] gcc-8: Disable libssp for non mingw targets [06/12] gcc-8: Disable float128 for ppc/musl [07/12] gcc-8: Enabled mspe options for rs6000 ppc backend [08/12] tcmode-default: Switch to gcc 8.0 [09/12] linux-yocto: Fix build with gcc8 for ppc [10/12] linux-yocto: Fix mips build with gcc8 [11/12] linux-yocto: Fix mips64 build with gcc8 [12/12] linux-yocto: Fix GCC 8 -Wrestrict error

Khem Raj June 6, 2018, 9:37 p.m. UTC

-march option is already used to select the base architecture
therefore using -mcpu which infact will reset march+mtune can
cause conflicts, therefore setting just mtune here will ensure
that the code is optimized for the given tune as is the intention
of mcpu, however with one advantage, it will be targetting broader
march value so can be useful for pre-compiled objects where they
can be run on wider subset

This also fixed occasional conflicts like

cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

which is possible combination in some case for packages in OE

Signed-off-by: Khem Raj <raj.khem@gmail.com>

---
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc       | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc     | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc     | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc      | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc      | 2 +-
 meta/conf/machine/include/tune-ep9312.inc        | 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc      | 2 +-
 meta/conf/machine/include/tune-xscale.inc        | 2 +-
 15 files changed, 15 insertions(+), 15 deletions(-)

-- 
2.17.1

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy June 6, 2018, 10:15 p.m. UTC | #1

On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:
> -march option is already used to select the base architecture

> therefore using -mcpu which infact will reset march+mtune can

> cause conflicts,


I think we need to at least understand how and why these conflicts
have started to occur with gcc 8. The tuning files themselves don't
contain any conflicts so the conflict must be coming from somewhere
else. Do we know where?

This patch is potentially going to hide bugs in cases where components
try to provide their own CPU specific flags rather than fully
respecting the flags set by OE. Generally we want to make those cases
fail so that we can debug and fix them.

> therefore setting just mtune here will ensure

> that the code is optimized for the given tune as is the intention

> of mcpu, however with one advantage, it will be targetting broader

> march value so can be useful for pre-compiled objects where they

> can be run on wider subset

>

> This also fixed occasional conflicts like

>

> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

>

> which is possible combination in some case for packages in OE

>

> Signed-off-by: Khem Raj <raj.khem@gmail.com>

> ---

>  meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

>  meta/conf/machine/include/tune-arm920t.inc       | 2 +-

>  meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

>  meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

>  meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

>  meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

>  meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

>  meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

>  meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

>  meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

>  meta/conf/machine/include/tune-ep9312.inc        | 2 +-

>  meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

>  meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

>  meta/conf/machine/include/tune-thunderx.inc      | 2 +-

>  meta/conf/machine/include/tune-xscale.inc        | 2 +-

>  15 files changed, 15 insertions(+), 15 deletions(-)

>

> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

> index c5de63e1cc..02114284e0 100644

> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

>  require conf/machine/include/arm/arch-armv6.inc

>

>  TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

>

>  AVAILTUNES += "arm1136jfs"

>  ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

> index c6e74b6772..5e6d4cbd91 100644

> --- a/meta/conf/machine/include/tune-arm920t.inc

> +++ b/meta/conf/machine/include/tune-arm920t.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>  require conf/machine/include/arm/arch-armv4.inc

>

>  TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

>

>  AVAILTUNES += "arm920t"

>  ARMPKGARCH_tune-arm920t = "arm920t"

> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

> index 81bcda339b..dddccaaae9 100644

> --- a/meta/conf/machine/include/tune-arm926ejs.inc

> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>  require conf/machine/include/arm/arch-armv5-dsp.inc

>

>  TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

>

>  AVAILTUNES += "arm926ejs"

>  ARMPKGARCH_tune-arm926ejs = "arm926ejs"

> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

> index e9c2b8fcf5..ebac472c5b 100644

> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>  require conf/machine/include/arm/arch-armv4.inc

>

>  TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

>

>  AVAILTUNES += "arm9tdmi"

>  ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

> index 25e99f93d7..0636306e2f 100644

> --- a/meta/conf/machine/include/tune-cortexa15.inc

> +++ b/meta/conf/machine/include/tune-cortexa15.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>  require conf/machine/include/arm/arch-armv7ve.inc

>

>  TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

> index 40392f9bcc..f9774b8b8e 100644

> --- a/meta/conf/machine/include/tune-cortexa17.inc

> +++ b/meta/conf/machine/include/tune-cortexa17.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>  require conf/machine/include/arm/arch-armv7ve.inc

>

>  TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

> index 1f0cda6640..1ececf9621 100644

> --- a/meta/conf/machine/include/tune-cortexa5.inc

> +++ b/meta/conf/machine/include/tune-cortexa5.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>  require conf/machine/include/arm/arch-armv7a.inc

>

>  TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

> index 52415d9c8b..08dd039338 100644

> --- a/meta/conf/machine/include/tune-cortexa7.inc

> +++ b/meta/conf/machine/include/tune-cortexa7.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>  require conf/machine/include/arm/arch-armv7ve.inc

>

>  TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

> index 8ee8de97f1..cdcb1c7d59 100644

> --- a/meta/conf/machine/include/tune-cortexa8.inc

> +++ b/meta/conf/machine/include/tune-cortexa8.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>  require conf/machine/include/arm/arch-armv7a.inc

>

>  TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

> index 0cf323c960..620178d18a 100644

> --- a/meta/conf/machine/include/tune-cortexa9.inc

> +++ b/meta/conf/machine/include/tune-cortexa9.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>  require conf/machine/include/arm/arch-armv7a.inc

>

>  TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

>

>  # Little Endian base configs

>  AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

> index 84ca528d6d..897b904cd1 100644

> --- a/meta/conf/machine/include/tune-ep9312.inc

> +++ b/meta/conf/machine/include/tune-ep9312.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

>  require conf/machine/include/arm/arch-armv4.inc

>

>  TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

>

>  AVAILTUNES += "ep9312"

>  ARMPKGARCH_tune-ep9312 = "ep9312"

> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

> index f27423cb2e..15cce8d3c5 100644

> --- a/meta/conf/machine/include/tune-iwmmxt.inc

> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

>  require conf/machine/include/arm/arch-armv5-dsp.inc

>

>  TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

>

>  AVAILTUNES += "iwmmxt"

>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

> index 80cfb8ab8a..7b2fa8e3ab 100644

> --- a/meta/conf/machine/include/tune-strongarm1100.inc

> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

>  require conf/machine/include/arm/arch-armv4.inc

>

>  TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

>

>  AVAILTUNES += "strongarm"

>  ARMPKGARCH_tune-strongarm = "strongarm"

> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

> index 3d43b0f7e5..e77d1cdd2d 100644

> --- a/meta/conf/machine/include/tune-thunderx.inc

> +++ b/meta/conf/machine/include/tune-thunderx.inc

> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

>

>  TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

>

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

>

>  ARMPKGARCH_tune-thunderx ?= "thunderx"

>  ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

> index 0d07333955..2a0610fddf 100644

> --- a/meta/conf/machine/include/tune-xscale.inc

> +++ b/meta/conf/machine/include/tune-xscale.inc

> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>  require conf/machine/include/arm/arch-armv5-dsp.inc

>

>  TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

>

>  AVAILTUNES += "xscale"

>  ARMPKGARCH_tune-xscale = "xscale"

> --

> 2.17.1

>

> --

> _______________________________________________

> Openembedded-core mailing list

> Openembedded-core@lists.openembedded.org

> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 6, 2018, 10:43 p.m. UTC | #2

On Wed, Jun 6, 2018 at 3:15 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> -march option is already used to select the base architecture

>> therefore using -mcpu which infact will reset march+mtune can

>> cause conflicts,

>

> I think we need to at least understand how and why these conflicts

> have started to occur with gcc 8. The tuning files themselves don't

> contain any conflicts so the conflict must be coming from somewhere

> else. Do we know where?


I explained it in previous emails as well, mcpu is a combination of march+mtune
how it reduces to these values depends on mcpu value. e.g. setting
mcpu=cortex-a7
would mean setting march=armv7ve and mtune to cortex-a7 internally
along with using code generator to use instructions available for that
cpu, thats why it errors out since it does not know which march to
use.
when we override one of these values on cmdline which we do then this can cause
the errors, these errors were happening before too see valgrind patch
its that gcc8 is catching more cases.

example is gcc-runtime/libstdc++ which deducts arch flags based on
configure options
and we do not pass narrow mcpu option to it since we build SDKs which
do not target
just one particular sub-family of cpu but rather a sub arch and if we
do not pass --with-cpu then it enforces some lowest common
denominator. When we say -mcpu then we
are actually asking the code to be generated for that particular CPU.

>

> This patch is potentially going to hide bugs in cases where components

> try to provide their own CPU specific flags rather than fully

> respecting the flags set by OE. Generally we want to make those cases

> fail so that we can debug and fix them.

>


No it wont. they can still do that. Last option wins so nothing changes there.
and in many cases it should be able to override specific flags for
specific packages
OE is a fall back for general default case.

A good change this does is that code is targeted for bigger base arch
e.g. armv7-a
and not for cortex-a8 but its tuned to run better on cortex-a8 when we
use -mtune
it will still run on other armv7-a based CPUs, so right now when we
say our package
arch is arm7ve but then use -mcpu=cortex-a7 we are actually doing wrong thing
this should have meant package arch to be cortex-a7 as well. Now this
will be more
inline as well.


>> therefore setting just mtune here will ensure

>> that the code is optimized for the given tune as is the intention

>> of mcpu, however with one advantage, it will be targetting broader

>> march value so can be useful for pre-compiled objects where they

>> can be run on wider subset

>>

>> This also fixed occasional conflicts like

>>

>> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

>>

>> which is possible combination in some case for packages in OE

>>

>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

>> ---

>>  meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

>>  meta/conf/machine/include/tune-arm920t.inc       | 2 +-

>>  meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

>>  meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

>>  meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

>>  meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

>>  meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

>>  meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

>>  meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

>>  meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

>>  meta/conf/machine/include/tune-ep9312.inc        | 2 +-

>>  meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

>>  meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

>>  meta/conf/machine/include/tune-thunderx.inc      | 2 +-

>>  meta/conf/machine/include/tune-xscale.inc        | 2 +-

>>  15 files changed, 15 insertions(+), 15 deletions(-)

>>

>> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

>> index c5de63e1cc..02114284e0 100644

>> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

>> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

>>  require conf/machine/include/arm/arch-armv6.inc

>>

>>  TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

>>

>>  AVAILTUNES += "arm1136jfs"

>>  ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

>> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

>> index c6e74b6772..5e6d4cbd91 100644

>> --- a/meta/conf/machine/include/tune-arm920t.inc

>> +++ b/meta/conf/machine/include/tune-arm920t.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>  require conf/machine/include/arm/arch-armv4.inc

>>

>>  TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

>>

>>  AVAILTUNES += "arm920t"

>>  ARMPKGARCH_tune-arm920t = "arm920t"

>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

>> index 81bcda339b..dddccaaae9 100644

>> --- a/meta/conf/machine/include/tune-arm926ejs.inc

>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>

>>  TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

>>

>>  AVAILTUNES += "arm926ejs"

>>  ARMPKGARCH_tune-arm926ejs = "arm926ejs"

>> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

>> index e9c2b8fcf5..ebac472c5b 100644

>> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

>> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>  require conf/machine/include/arm/arch-armv4.inc

>>

>>  TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

>>

>>  AVAILTUNES += "arm9tdmi"

>>  ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

>> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

>> index 25e99f93d7..0636306e2f 100644

>> --- a/meta/conf/machine/include/tune-cortexa15.inc

>> +++ b/meta/conf/machine/include/tune-cortexa15.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>  require conf/machine/include/arm/arch-armv7ve.inc

>>

>>  TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

>> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

>> index 40392f9bcc..f9774b8b8e 100644

>> --- a/meta/conf/machine/include/tune-cortexa17.inc

>> +++ b/meta/conf/machine/include/tune-cortexa17.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>  require conf/machine/include/arm/arch-armv7ve.inc

>>

>>  TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

>> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

>> index 1f0cda6640..1ececf9621 100644

>> --- a/meta/conf/machine/include/tune-cortexa5.inc

>> +++ b/meta/conf/machine/include/tune-cortexa5.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>  require conf/machine/include/arm/arch-armv7a.inc

>>

>>  TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

>> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

>> index 52415d9c8b..08dd039338 100644

>> --- a/meta/conf/machine/include/tune-cortexa7.inc

>> +++ b/meta/conf/machine/include/tune-cortexa7.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>  require conf/machine/include/arm/arch-armv7ve.inc

>>

>>  TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

>> index 8ee8de97f1..cdcb1c7d59 100644

>> --- a/meta/conf/machine/include/tune-cortexa8.inc

>> +++ b/meta/conf/machine/include/tune-cortexa8.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>  require conf/machine/include/arm/arch-armv7a.inc

>>

>>  TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

>> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

>> index 0cf323c960..620178d18a 100644

>> --- a/meta/conf/machine/include/tune-cortexa9.inc

>> +++ b/meta/conf/machine/include/tune-cortexa9.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>  require conf/machine/include/arm/arch-armv7a.inc

>>

>>  TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

>>

>>  # Little Endian base configs

>>  AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

>> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

>> index 84ca528d6d..897b904cd1 100644

>> --- a/meta/conf/machine/include/tune-ep9312.inc

>> +++ b/meta/conf/machine/include/tune-ep9312.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

>>  require conf/machine/include/arm/arch-armv4.inc

>>

>>  TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

>>

>>  AVAILTUNES += "ep9312"

>>  ARMPKGARCH_tune-ep9312 = "ep9312"

>> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

>> index f27423cb2e..15cce8d3c5 100644

>> --- a/meta/conf/machine/include/tune-iwmmxt.inc

>> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

>> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>

>>  TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

>>

>>  AVAILTUNES += "iwmmxt"

>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

>> index 80cfb8ab8a..7b2fa8e3ab 100644

>> --- a/meta/conf/machine/include/tune-strongarm1100.inc

>> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

>>  require conf/machine/include/arm/arch-armv4.inc

>>

>>  TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

>>

>>  AVAILTUNES += "strongarm"

>>  ARMPKGARCH_tune-strongarm = "strongarm"

>> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

>> index 3d43b0f7e5..e77d1cdd2d 100644

>> --- a/meta/conf/machine/include/tune-thunderx.inc

>> +++ b/meta/conf/machine/include/tune-thunderx.inc

>> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

>>

>>  TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

>>

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

>>

>>  ARMPKGARCH_tune-thunderx ?= "thunderx"

>>  ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

>> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

>> index 0d07333955..2a0610fddf 100644

>> --- a/meta/conf/machine/include/tune-xscale.inc

>> +++ b/meta/conf/machine/include/tune-xscale.inc

>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>

>>  TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

>>

>>  AVAILTUNES += "xscale"

>>  ARMPKGARCH_tune-xscale = "xscale"

>> --

>> 2.17.1

>>

>> --

>> _______________________________________________

>> Openembedded-core mailing list

>> Openembedded-core@lists.openembedded.org

>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy June 6, 2018, 11:42 p.m. UTC | #3

On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 3:15 PM, Andre McCurdy <armccurdy@gmail.com> wrote:

>> On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>> -march option is already used to select the base architecture

>>> therefore using -mcpu which infact will reset march+mtune can

>>> cause conflicts,

>>

>> I think we need to at least understand how and why these conflicts

>> have started to occur with gcc 8. The tuning files themselves don't

>> contain any conflicts so the conflict must be coming from somewhere

>> else. Do we know where?

>

> I explained it in previous emails as well, mcpu is a combination of march+mtune

> how it reduces to these values depends on mcpu value. e.g. setting

> mcpu=cortex-a7

> would mean setting march=armv7ve and mtune to cortex-a7 internally

> along with using code generator to use instructions available for that

> cpu, thats why it errors out since it does not know which march to

> use.

> when we override one of these values on cmdline which we do then this can cause

> the errors, these errors were happening before too see valgrind patch

> its that gcc8 is catching more cases.


The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch
the same conflicts. It doesn't make sense that gcc8 is just catching
more issues.

The valgrind case is not a good example. The conflict there comes
because we leak CFLAGS intended for the target into Makefiles which
valgrind uses to build test apps which are intended to only run under
valgrind (ie NOT directly on the target). The real fix there would be
to prevent the target specific flags being passed to build for those
few valgrind test apps.

> example is gcc-runtime/libstdc++ which deducts arch flags based on

> configure options

> and we do not pass narrow mcpu option to it since we build SDKs which

> do not target

> just one particular sub-family of cpu but rather a sub arch

> do not pass --with-cpu then it enforces some lowest common

> denominator. When we say -mcpu then we

> are actually asking the code to be generated for that particular CPU.


If we are trying to build something which is reusable across multiple
machines with the same architecture then it's a bug to be passing
machine specific CFLAGS. Making the machine specific CFLAGS more
generic is not the right solution.

Anyway, I suspect the real issue here is that when we build gcc to run
on the target we currently configure using "--with-arch=armv7-a" for
both armv7a and armv7ve. It was done that way deliberately to try to
avoid rebuilds when switching between armv7a and armv7ve machines,
although thinking about that now I'm not sure it makes so much sense.
Does your original problem go away if you simply change:

  EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

to

  EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

in gcc-target.inc ?

>>

>> This patch is potentially going to hide bugs in cases where components

>> try to provide their own CPU specific flags rather than fully

>> respecting the flags set by OE. Generally we want to make those cases

>> fail so that we can debug and fix them.

>>

>

> No it wont. they can still do that. Last option wins so nothing changes there.


The thing that changes is that after your patch, gcc will no longer
report a conflict!

> and in many cases it should be able to override specific flags for

> specific packages

> OE is a fall back for general default case.

>

> A good change this does is that code is targeted for bigger base arch

> e.g. armv7-a

> and not for cortex-a8 but its tuned to run better on cortex-a8 when we

> use -mtune

> it will still run on other armv7-a based CPUs, so right now when we

> say our package

> arch is arm7ve but then use -mcpu=cortex-a7 we are actually doing wrong thing

> this should have meant package arch to be cortex-a7 as well. Now this

> will be more

> inline as well.

>

>

>>> therefore setting just mtune here will ensure

>>> that the code is optimized for the given tune as is the intention

>>> of mcpu, however with one advantage, it will be targetting broader

>>> march value so can be useful for pre-compiled objects where they

>>> can be run on wider subset

>>>

>>> This also fixed occasional conflicts like

>>>

>>> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

>>>

>>> which is possible combination in some case for packages in OE

>>>

>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

>>> ---

>>>  meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

>>>  meta/conf/machine/include/tune-arm920t.inc       | 2 +-

>>>  meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

>>>  meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

>>>  meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

>>>  meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

>>>  meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

>>>  meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

>>>  meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

>>>  meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

>>>  meta/conf/machine/include/tune-ep9312.inc        | 2 +-

>>>  meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

>>>  meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

>>>  meta/conf/machine/include/tune-thunderx.inc      | 2 +-

>>>  meta/conf/machine/include/tune-xscale.inc        | 2 +-

>>>  15 files changed, 15 insertions(+), 15 deletions(-)

>>>

>>> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

>>> index c5de63e1cc..02114284e0 100644

>>> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

>>> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

>>>  require conf/machine/include/arm/arch-armv6.inc

>>>

>>>  TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

>>>

>>>  AVAILTUNES += "arm1136jfs"

>>>  ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

>>> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

>>> index c6e74b6772..5e6d4cbd91 100644

>>> --- a/meta/conf/machine/include/tune-arm920t.inc

>>> +++ b/meta/conf/machine/include/tune-arm920t.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>>  require conf/machine/include/arm/arch-armv4.inc

>>>

>>>  TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

>>>

>>>  AVAILTUNES += "arm920t"

>>>  ARMPKGARCH_tune-arm920t = "arm920t"

>>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

>>> index 81bcda339b..dddccaaae9 100644

>>> --- a/meta/conf/machine/include/tune-arm926ejs.inc

>>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>>

>>>  TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

>>>

>>>  AVAILTUNES += "arm926ejs"

>>>  ARMPKGARCH_tune-arm926ejs = "arm926ejs"

>>> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

>>> index e9c2b8fcf5..ebac472c5b 100644

>>> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

>>> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>>  require conf/machine/include/arm/arch-armv4.inc

>>>

>>>  TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

>>>

>>>  AVAILTUNES += "arm9tdmi"

>>>  ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

>>> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

>>> index 25e99f93d7..0636306e2f 100644

>>> --- a/meta/conf/machine/include/tune-cortexa15.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa15.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>  require conf/machine/include/arm/arch-armv7ve.inc

>>>

>>>  TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

>>> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

>>> index 40392f9bcc..f9774b8b8e 100644

>>> --- a/meta/conf/machine/include/tune-cortexa17.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa17.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>  require conf/machine/include/arm/arch-armv7ve.inc

>>>

>>>  TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

>>> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

>>> index 1f0cda6640..1ececf9621 100644

>>> --- a/meta/conf/machine/include/tune-cortexa5.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa5.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>  require conf/machine/include/arm/arch-armv7a.inc

>>>

>>>  TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

>>> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

>>> index 52415d9c8b..08dd039338 100644

>>> --- a/meta/conf/machine/include/tune-cortexa7.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa7.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>  require conf/machine/include/arm/arch-armv7ve.inc

>>>

>>>  TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

>>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

>>> index 8ee8de97f1..cdcb1c7d59 100644

>>> --- a/meta/conf/machine/include/tune-cortexa8.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa8.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>  require conf/machine/include/arm/arch-armv7a.inc

>>>

>>>  TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

>>> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

>>> index 0cf323c960..620178d18a 100644

>>> --- a/meta/conf/machine/include/tune-cortexa9.inc

>>> +++ b/meta/conf/machine/include/tune-cortexa9.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>  require conf/machine/include/arm/arch-armv7a.inc

>>>

>>>  TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

>>>

>>>  # Little Endian base configs

>>>  AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

>>> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

>>> index 84ca528d6d..897b904cd1 100644

>>> --- a/meta/conf/machine/include/tune-ep9312.inc

>>> +++ b/meta/conf/machine/include/tune-ep9312.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

>>>  require conf/machine/include/arm/arch-armv4.inc

>>>

>>>  TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

>>>

>>>  AVAILTUNES += "ep9312"

>>>  ARMPKGARCH_tune-ep9312 = "ep9312"

>>> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

>>> index f27423cb2e..15cce8d3c5 100644

>>> --- a/meta/conf/machine/include/tune-iwmmxt.inc

>>> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

>>> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

>>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>>

>>>  TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

>>>

>>>  AVAILTUNES += "iwmmxt"

>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>>> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

>>> index 80cfb8ab8a..7b2fa8e3ab 100644

>>> --- a/meta/conf/machine/include/tune-strongarm1100.inc

>>> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

>>>  require conf/machine/include/arm/arch-armv4.inc

>>>

>>>  TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

>>>

>>>  AVAILTUNES += "strongarm"

>>>  ARMPKGARCH_tune-strongarm = "strongarm"

>>> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

>>> index 3d43b0f7e5..e77d1cdd2d 100644

>>> --- a/meta/conf/machine/include/tune-thunderx.inc

>>> +++ b/meta/conf/machine/include/tune-thunderx.inc

>>> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

>>>

>>>  TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

>>>

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

>>>

>>>  ARMPKGARCH_tune-thunderx ?= "thunderx"

>>>  ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

>>> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

>>> index 0d07333955..2a0610fddf 100644

>>> --- a/meta/conf/machine/include/tune-xscale.inc

>>> +++ b/meta/conf/machine/include/tune-xscale.inc

>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>>  require conf/machine/include/arm/arch-armv5-dsp.inc

>>>

>>>  TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

>>>

>>>  AVAILTUNES += "xscale"

>>>  ARMPKGARCH_tune-xscale = "xscale"

>>> --

>>> 2.17.1

>>>

>>> --

>>> _______________________________________________

>>> Openembedded-core mailing list

>>> Openembedded-core@lists.openembedded.org

>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 7, 2018, 5:58 a.m. UTC | #4

On 6/6/18 4:42 PM, Andre McCurdy wrote:
> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> On Wed, Jun 6, 2018 at 3:15 PM, Andre McCurdy <armccurdy@gmail.com> wrote:

>>> On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>> -march option is already used to select the base architecture

>>>> therefore using -mcpu which infact will reset march+mtune can

>>>> cause conflicts,

>>>

>>> I think we need to at least understand how and why these conflicts

>>> have started to occur with gcc 8. The tuning files themselves don't

>>> contain any conflicts so the conflict must be coming from somewhere

>>> else. Do we know where?

>>

>> I explained it in previous emails as well, mcpu is a combination of march+mtune

>> how it reduces to these values depends on mcpu value. e.g. setting

>> mcpu=cortex-a7

>> would mean setting march=armv7ve and mtune to cortex-a7 internally

>> along with using code generator to use instructions available for that

>> cpu, thats why it errors out since it does not know which march to

>> use.

>> when we override one of these values on cmdline which we do then this can cause

>> the errors, these errors were happening before too see valgrind patch

>> its that gcc8 is catching more cases.

> 

> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

> the same conflicts. It doesn't make sense that gcc8 is just catching

> more issues.


It does make sense. the option parsing for these specific options on arm 
have been revamped after gcc7, see

https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

> 

> The valgrind case is not a good example. The conflict there comes

> because we leak CFLAGS intended for the target into Makefiles which

> valgrind uses to build test apps which are intended to only run under

> valgrind (ie NOT directly on the target). The real fix there would be

> to prevent the target specific flags being passed to build for those

> few valgrind test apps.

> 


it is manifesting similar conflicts

>> example is gcc-runtime/libstdc++ which deducts arch flags based on

>> configure options

>> and we do not pass narrow mcpu option to it since we build SDKs which

>> do not target

>> just one particular sub-family of cpu but rather a sub arch

>> do not pass --with-cpu then it enforces some lowest common

>> denominator. When we say -mcpu then we

>> are actually asking the code to be generated for that particular CPU.

> 

> If we are trying to build something which is reusable across multiple

> machines with the same architecture then it's a bug to be passing

> machine specific CFLAGS. Making the machine specific CFLAGS more

> generic is not the right solution.


being reusable is a side-effect and a good one. Real problem is we are 
not matching to what we say in package arches, Probably you are 
confusing tunes to be meant for static code generation for a given CPU. 
I am interested to hear more ideas to what would be right solution if 
this is not it.

> 

> Anyway, I suspect the real issue here is that when we build gcc to run

> on the target we currently configure using "--with-arch=armv7-a" for

> both armv7a and armv7ve. It was done that way deliberately to try to

> avoid rebuilds when switching between armv7a and armv7ve machines,

> although thinking about that now I'm not sure it makes so much sense.

> Does your original problem go away if you simply change:

> 

>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

> 

> to

> 

>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

> 

> in gcc-target.inc ?


No, this is not the problem I am talking about gcc-runtime which is 
configured during cross build but built for target later on.

talking about this case, changing --with-arch will make on device gcc 
complain about mismatches with default runtime since it is meant to use 
same runtime that will be built above.  Using armv7-a here is a 
conscious choice.

> 

>>>

>>> This patch is potentially going to hide bugs in cases where components

>>> try to provide their own CPU specific flags rather than fully

>>> respecting the flags set by OE. Generally we want to make those cases

>>> fail so that we can debug and fix them.

>>>

>>

>> No it wont. they can still do that. Last option wins so nothing changes there.

> 

> The thing that changes is that after your patch, gcc will no longer

> report a conflict!

> 

>> and in many cases it should be able to override specific flags for

>> specific packages

>> OE is a fall back for general default case.

>>

>> A good change this does is that code is targeted for bigger base arch

>> e.g. armv7-a

>> and not for cortex-a8 but its tuned to run better on cortex-a8 when we

>> use -mtune

>> it will still run on other armv7-a based CPUs, so right now when we

>> say our package

>> arch is arm7ve but then use -mcpu=cortex-a7 we are actually doing wrong thing

>> this should have meant package arch to be cortex-a7 as well. Now this

>> will be more

>> inline as well.

>>

>>

>>>> therefore setting just mtune here will ensure

>>>> that the code is optimized for the given tune as is the intention

>>>> of mcpu, however with one advantage, it will be targetting broader

>>>> march value so can be useful for pre-compiled objects where they

>>>> can be run on wider subset

>>>>

>>>> This also fixed occasional conflicts like

>>>>

>>>> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

>>>>

>>>> which is possible combination in some case for packages in OE

>>>>

>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

>>>> ---

>>>>   meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

>>>>   meta/conf/machine/include/tune-arm920t.inc       | 2 +-

>>>>   meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

>>>>   meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-ep9312.inc        | 2 +-

>>>>   meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

>>>>   meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

>>>>   meta/conf/machine/include/tune-thunderx.inc      | 2 +-

>>>>   meta/conf/machine/include/tune-xscale.inc        | 2 +-

>>>>   15 files changed, 15 insertions(+), 15 deletions(-)

>>>>

>>>> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

>>>> index c5de63e1cc..02114284e0 100644

>>>> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

>>>> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

>>>>   require conf/machine/include/arm/arch-armv6.inc

>>>>

>>>>   TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

>>>>

>>>>   AVAILTUNES += "arm1136jfs"

>>>>   ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

>>>> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

>>>> index c6e74b6772..5e6d4cbd91 100644

>>>> --- a/meta/conf/machine/include/tune-arm920t.inc

>>>> +++ b/meta/conf/machine/include/tune-arm920t.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>>>   require conf/machine/include/arm/arch-armv4.inc

>>>>

>>>>   TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

>>>>

>>>>   AVAILTUNES += "arm920t"

>>>>   ARMPKGARCH_tune-arm920t = "arm920t"

>>>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

>>>> index 81bcda339b..dddccaaae9 100644

>>>> --- a/meta/conf/machine/include/tune-arm926ejs.inc

>>>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>>>>

>>>>   TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

>>>>

>>>>   AVAILTUNES += "arm926ejs"

>>>>   ARMPKGARCH_tune-arm926ejs = "arm926ejs"

>>>> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

>>>> index e9c2b8fcf5..ebac472c5b 100644

>>>> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

>>>> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>>>>   require conf/machine/include/arm/arch-armv4.inc

>>>>

>>>>   TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

>>>>

>>>>   AVAILTUNES += "arm9tdmi"

>>>>   ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

>>>> index 25e99f93d7..0636306e2f 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa15.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa15.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>>   require conf/machine/include/arm/arch-armv7ve.inc

>>>>

>>>>   TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

>>>> index 40392f9bcc..f9774b8b8e 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa17.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa17.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>>   require conf/machine/include/arm/arch-armv7ve.inc

>>>>

>>>>   TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

>>>> index 1f0cda6640..1ececf9621 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa5.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa5.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>>   require conf/machine/include/arm/arch-armv7a.inc

>>>>

>>>>   TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

>>>> index 52415d9c8b..08dd039338 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa7.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa7.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>>>>   require conf/machine/include/arm/arch-armv7ve.inc

>>>>

>>>>   TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

>>>> index 8ee8de97f1..cdcb1c7d59 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa8.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa8.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>>   require conf/machine/include/arm/arch-armv7a.inc

>>>>

>>>>   TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

>>>> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

>>>> index 0cf323c960..620178d18a 100644

>>>> --- a/meta/conf/machine/include/tune-cortexa9.inc

>>>> +++ b/meta/conf/machine/include/tune-cortexa9.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>>>>   require conf/machine/include/arm/arch-armv7a.inc

>>>>

>>>>   TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

>>>>

>>>>   # Little Endian base configs

>>>>   AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

>>>> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

>>>> index 84ca528d6d..897b904cd1 100644

>>>> --- a/meta/conf/machine/include/tune-ep9312.inc

>>>> +++ b/meta/conf/machine/include/tune-ep9312.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

>>>>   require conf/machine/include/arm/arch-armv4.inc

>>>>

>>>>   TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

>>>>

>>>>   AVAILTUNES += "ep9312"

>>>>   ARMPKGARCH_tune-ep9312 = "ep9312"

>>>> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

>>>> index f27423cb2e..15cce8d3c5 100644

>>>> --- a/meta/conf/machine/include/tune-iwmmxt.inc

>>>> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

>>>> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

>>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>>>>

>>>>   TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

>>>>

>>>>   AVAILTUNES += "iwmmxt"

>>>>   ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>>>> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

>>>> index 80cfb8ab8a..7b2fa8e3ab 100644

>>>> --- a/meta/conf/machine/include/tune-strongarm1100.inc

>>>> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

>>>>   require conf/machine/include/arm/arch-armv4.inc

>>>>

>>>>   TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

>>>>

>>>>   AVAILTUNES += "strongarm"

>>>>   ARMPKGARCH_tune-strongarm = "strongarm"

>>>> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

>>>> index 3d43b0f7e5..e77d1cdd2d 100644

>>>> --- a/meta/conf/machine/include/tune-thunderx.inc

>>>> +++ b/meta/conf/machine/include/tune-thunderx.inc

>>>> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

>>>>

>>>>   TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

>>>>

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

>>>>

>>>>   ARMPKGARCH_tune-thunderx ?= "thunderx"

>>>>   ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

>>>> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

>>>> index 0d07333955..2a0610fddf 100644

>>>> --- a/meta/conf/machine/include/tune-xscale.inc

>>>> +++ b/meta/conf/machine/include/tune-xscale.inc

>>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>>>>

>>>>   TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

>>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

>>>>

>>>>   AVAILTUNES += "xscale"

>>>>   ARMPKGARCH_tune-xscale = "xscale"

>>>> --

>>>> 2.17.1

>>>>

>>>> --

>>>> _______________________________________________

>>>> Openembedded-core mailing list

>>>> Openembedded-core@lists.openembedded.org

>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Martin Jansa June 7, 2018, 6:36 a.m. UTC | #5

On Wed, Jun 06, 2018 at 10:58:19PM -0700, Khem Raj wrote:
> 

> 

> On 6/6/18 4:42 PM, Andre McCurdy wrote:

> > On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

> >> On Wed, Jun 6, 2018 at 3:15 PM, Andre McCurdy <armccurdy@gmail.com> wrote:

> >>> On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

> >>>> -march option is already used to select the base architecture

> >>>> therefore using -mcpu which infact will reset march+mtune can

> >>>> cause conflicts,

> >>>

> >>> I think we need to at least understand how and why these conflicts

> >>> have started to occur with gcc 8. The tuning files themselves don't

> >>> contain any conflicts so the conflict must be coming from somewhere

> >>> else. Do we know where?

> >>

> >> I explained it in previous emails as well, mcpu is a combination of march+mtune

> >> how it reduces to these values depends on mcpu value. e.g. setting

> >> mcpu=cortex-a7

> >> would mean setting march=armv7ve and mtune to cortex-a7 internally

> >> along with using code generator to use instructions available for that

> >> cpu, thats why it errors out since it does not know which march to

> >> use.

> >> when we override one of these values on cmdline which we do then this can cause

> >> the errors, these errors were happening before too see valgrind patch

> >> its that gcc8 is catching more cases.

> > 

> > The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

> > the same conflicts. It doesn't make sense that gcc8 is just catching

> > more issues.

> 

> It does make sense. the option parsing for these specific options on arm 

> have been revamped after gcc7, see

> 

> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

> 

> > 

> > The valgrind case is not a good example. The conflict there comes

> > because we leak CFLAGS intended for the target into Makefiles which

> > valgrind uses to build test apps which are intended to only run under

> > valgrind (ie NOT directly on the target). The real fix there would be

> > to prevent the target specific flags being passed to build for those

> > few valgrind test apps.

> > 

> 

> it is manifesting similar conflicts

> 

> >> example is gcc-runtime/libstdc++ which deducts arch flags based on

> >> configure options

> >> and we do not pass narrow mcpu option to it since we build SDKs which

> >> do not target

> >> just one particular sub-family of cpu but rather a sub arch

> >> do not pass --with-cpu then it enforces some lowest common

> >> denominator. When we say -mcpu then we

> >> are actually asking the code to be generated for that particular CPU.

> > 

> > If we are trying to build something which is reusable across multiple

> > machines with the same architecture then it's a bug to be passing

> > machine specific CFLAGS. Making the machine specific CFLAGS more

> > generic is not the right solution.

> 

> being reusable is a side-effect and a good one. Real problem is we are 

> not matching to what we say in package arches, Probably you are 

> confusing tunes to be meant for static code generation for a given CPU. 

> I am interested to hear more ideas to what would be right solution if 

> this is not it.


I don't agree with this part, you're basically reverting the change from:
http://git.openembedded.org/openembedded-core/commit/?id=f7bb2d4cf18ca8d2a90b4b3b5c6c48dad106ca28
but since:
http://git.openembedded.org/openembedded-core/commit/?id=cffda9a821a3b83a8529d643c567859e091c6846
we already have different ARMPKGARCH for each DEFAULT_TUNE with
different -mcpu option.

If you want to target more generic configuration than you should use
more generic DEFAULT_TUNE and even the default configuration will select
something generic, e.g.:
http://git.openembedded.org/openembedded-core/tree/meta/conf/machine/include/tune-cortexa8.inc
sets
DEFAULTTUNE ?= "armv7athf-neon"
so no -mcpu options unless you explicitly ask for it by selecting
more specific DEFAULT_TUNE in DISTRO config.

> > Anyway, I suspect the real issue here is that when we build gcc to run

> > on the target we currently configure using "--with-arch=armv7-a" for

> > both armv7a and armv7ve. It was done that way deliberately to try to

> > avoid rebuilds when switching between armv7a and armv7ve machines,

> > although thinking about that now I'm not sure it makes so much sense.

> > Does your original problem go away if you simply change:

> > 

> >    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

> > 

> > to

> > 

> >    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

> > 

> > in gcc-target.inc ?

> 

> No, this is not the problem I am talking about gcc-runtime which is 

> configured during cross build but built for target later on.

> 

> talking about this case, changing --with-arch will make on device gcc 

> complain about mismatches with default runtime since it is meant to use 

> same runtime that will be built above.  Using armv7-a here is a 

> conscious choice.


I've already tried this as well, because that's what I was doing long
time ago with the tune files:
http://git.openembedded.org/openembedded-core/commit/meta/conf/machine/include?id=35392025f3236f5e5393f9cf0857732da9a2e503

but it's true that gcc-runtime is a bit more complicated by that, it
doesn't use gcc-target.inc (gcc-target.inc is only used by gcc itself),
so I've tried to move the --with-arch options a bit lower to
gcc-configure-common.inc where we already set the archs for MIPS, but it
didn't work well, at least as done in:
https://pastebin.com/3Cc5MYBa

and then I've moved to something else and never finished this one.

> 

> > 

> >>>

> >>> This patch is potentially going to hide bugs in cases where components

> >>> try to provide their own CPU specific flags rather than fully

> >>> respecting the flags set by OE. Generally we want to make those cases

> >>> fail so that we can debug and fix them.

> >>>

> >>

> >> No it wont. they can still do that. Last option wins so nothing changes there.

> > 

> > The thing that changes is that after your patch, gcc will no longer

> > report a conflict!

> > 

> >> and in many cases it should be able to override specific flags for

> >> specific packages

> >> OE is a fall back for general default case.

> >>

> >> A good change this does is that code is targeted for bigger base arch

> >> e.g. armv7-a

> >> and not for cortex-a8 but its tuned to run better on cortex-a8 when we

> >> use -mtune

> >> it will still run on other armv7-a based CPUs, so right now when we

> >> say our package

> >> arch is arm7ve but then use -mcpu=cortex-a7 we are actually doing wrong thing

> >> this should have meant package arch to be cortex-a7 as well. Now this

> >> will be more

> >> inline as well.

> >>

> >>

> >>>> therefore setting just mtune here will ensure

> >>>> that the code is optimized for the given tune as is the intention

> >>>> of mcpu, however with one advantage, it will be targetting broader

> >>>> march value so can be useful for pre-compiled objects where they

> >>>> can be run on wider subset

> >>>>

> >>>> This also fixed occasional conflicts like

> >>>>

> >>>> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

> >>>>

> >>>> which is possible combination in some case for packages in OE

> >>>>

> >>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

> >>>> ---

> >>>>   meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

> >>>>   meta/conf/machine/include/tune-arm920t.inc       | 2 +-

> >>>>   meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

> >>>>   meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-ep9312.inc        | 2 +-

> >>>>   meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

> >>>>   meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

> >>>>   meta/conf/machine/include/tune-thunderx.inc      | 2 +-

> >>>>   meta/conf/machine/include/tune-xscale.inc        | 2 +-

> >>>>   15 files changed, 15 insertions(+), 15 deletions(-)

> >>>>

> >>>> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

> >>>> index c5de63e1cc..02114284e0 100644

> >>>> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

> >>>> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

> >>>>   require conf/machine/include/arm/arch-armv6.inc

> >>>>

> >>>>   TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "arm1136jfs"

> >>>>   ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

> >>>> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

> >>>> index c6e74b6772..5e6d4cbd91 100644

> >>>> --- a/meta/conf/machine/include/tune-arm920t.inc

> >>>> +++ b/meta/conf/machine/include/tune-arm920t.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

> >>>>   require conf/machine/include/arm/arch-armv4.inc

> >>>>

> >>>>   TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "arm920t"

> >>>>   ARMPKGARCH_tune-arm920t = "arm920t"

> >>>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

> >>>> index 81bcda339b..dddccaaae9 100644

> >>>> --- a/meta/conf/machine/include/tune-arm926ejs.inc

> >>>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

> >>>>

> >>>>   TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "arm926ejs"

> >>>>   ARMPKGARCH_tune-arm926ejs = "arm926ejs"

> >>>> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

> >>>> index e9c2b8fcf5..ebac472c5b 100644

> >>>> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

> >>>> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

> >>>>   require conf/machine/include/arm/arch-armv4.inc

> >>>>

> >>>>   TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "arm9tdmi"

> >>>>   ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

> >>>> index 25e99f93d7..0636306e2f 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa15.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa15.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

> >>>>

> >>>>   TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

> >>>> index 40392f9bcc..f9774b8b8e 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa17.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa17.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

> >>>>

> >>>>   TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

> >>>> index 1f0cda6640..1ececf9621 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa5.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa5.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7a.inc

> >>>>

> >>>>   TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

> >>>> index 52415d9c8b..08dd039338 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa7.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa7.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

> >>>>

> >>>>   TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

> >>>> index 8ee8de97f1..cdcb1c7d59 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa8.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa8.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7a.inc

> >>>>

> >>>>   TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

> >>>> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

> >>>> index 0cf323c960..620178d18a 100644

> >>>> --- a/meta/conf/machine/include/tune-cortexa9.inc

> >>>> +++ b/meta/conf/machine/include/tune-cortexa9.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

> >>>>   require conf/machine/include/arm/arch-armv7a.inc

> >>>>

> >>>>   TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

> >>>>

> >>>>   # Little Endian base configs

> >>>>   AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

> >>>> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

> >>>> index 84ca528d6d..897b904cd1 100644

> >>>> --- a/meta/conf/machine/include/tune-ep9312.inc

> >>>> +++ b/meta/conf/machine/include/tune-ep9312.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

> >>>>   require conf/machine/include/arm/arch-armv4.inc

> >>>>

> >>>>   TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "ep9312"

> >>>>   ARMPKGARCH_tune-ep9312 = "ep9312"

> >>>> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

> >>>> index f27423cb2e..15cce8d3c5 100644

> >>>> --- a/meta/conf/machine/include/tune-iwmmxt.inc

> >>>> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

> >>>> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

> >>>>

> >>>>   TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "iwmmxt"

> >>>>   ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> >>>> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

> >>>> index 80cfb8ab8a..7b2fa8e3ab 100644

> >>>> --- a/meta/conf/machine/include/tune-strongarm1100.inc

> >>>> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

> >>>>   require conf/machine/include/arm/arch-armv4.inc

> >>>>

> >>>>   TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "strongarm"

> >>>>   ARMPKGARCH_tune-strongarm = "strongarm"

> >>>> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

> >>>> index 3d43b0f7e5..e77d1cdd2d 100644

> >>>> --- a/meta/conf/machine/include/tune-thunderx.inc

> >>>> +++ b/meta/conf/machine/include/tune-thunderx.inc

> >>>> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

> >>>>

> >>>>   TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

> >>>>

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

> >>>>

> >>>>   ARMPKGARCH_tune-thunderx ?= "thunderx"

> >>>>   ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

> >>>> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

> >>>> index 0d07333955..2a0610fddf 100644

> >>>> --- a/meta/conf/machine/include/tune-xscale.inc

> >>>> +++ b/meta/conf/machine/include/tune-xscale.inc

> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

> >>>>

> >>>>   TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

> >>>>

> >>>>   AVAILTUNES += "xscale"

> >>>>   ARMPKGARCH_tune-xscale = "xscale"

> >>>> --

> >>>> 2.17.1

> >>>>

> >>>> --

> >>>> _______________________________________________

> >>>> Openembedded-core mailing list

> >>>> Openembedded-core@lists.openembedded.org

> >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

> -- 

> _______________________________________________

> Openembedded-core mailing list

> Openembedded-core@lists.openembedded.org

> http://lists.openembedded.org/mailman/listinfo/openembedded-core


-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy June 7, 2018, 7:14 a.m. UTC | #6

On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>

>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>> the same conflicts. It doesn't make sense that gcc8 is just catching

>> more issues.

>

> It does make sense. the option parsing for these specific options on arm

> have been revamped after gcc7, see

>

> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7


Thanks. These commits seem to be related to handling of options like
"-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

If you can provide the command line that caused the error then it
should be quick to establish whether it's gcc8 being more picky.

Or perhaps there's always been a warning and -Werror has been added to
a gcc8 Makefile where it wasn't before?

>> If we are trying to build something which is reusable across multiple

>> machines with the same architecture then it's a bug to be passing

>> machine specific CFLAGS. Making the machine specific CFLAGS more

>> generic is not the right solution.

>

> being reusable is a side-effect and a good one. Real problem is we are not

> matching to what we say in package arches, Probably you are confusing tunes

> to be meant for static code generation for a given CPU.


Sorry, I don't really follow what you mean?

> I am interested to

> hear more ideas to what would be right solution if this is not it.


I'd like to understand what the problem is first before trying to
propose any solutions.

ie what specifically has changed with gcc8 to cause the error which
wasn't seen before?

>> Anyway, I suspect the real issue here is that when we build gcc to run

>> on the target we currently configure using "--with-arch=armv7-a" for

>> both armv7a and armv7ve. It was done that way deliberately to try to

>> avoid rebuilds when switching between armv7a and armv7ve machines,

>> although thinking about that now I'm not sure it makes so much sense.

>> Does your original problem go away if you simply change:

>>

>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

>>

>> to

>>

>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

>>

>> in gcc-target.inc ?

>

> No, this is not the problem I am talking about gcc-runtime which is

> configured during cross build but built for target later on.


OK, good to rule that out. It's nothing to do with gcc8 and I've sent
a separate patch to fix it.
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 7, 2018, 2:04 p.m. UTC | #7

On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>

>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>> more issues.

>>

>> It does make sense. the option parsing for these specific options on arm

>> have been revamped after gcc7, see

>>

>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>

> Thanks. These commits seem to be related to handling of options like

> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>

> If you can provide the command line that caused the error then it

> should be quick to establish whether it's gcc8 being more picky.

>

> Or perhaps there's always been a warning and -Werror has been added to

> a gcc8 Makefile where it wasn't before?

>

>>> If we are trying to build something which is reusable across multiple

>>> machines with the same architecture then it's a bug to be passing

>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>> generic is not the right solution.

>>

>> being reusable is a side-effect and a good one. Real problem is we are not

>> matching to what we say in package arches, Probably you are confusing tunes

>> to be meant for static code generation for a given CPU.

>

> Sorry, I don't really follow what you mean?

>

>> I am interested to

>> hear more ideas to what would be right solution if this is not it.

>

> I'd like to understand what the problem is first before trying to

> propose any solutions.

>

> ie what specifically has changed with gcc8 to cause the error which

> wasn't seen before?



I would suggest take this gcc8 patch series and revert this one then build
gcc-runtime for rpi3

>

>>> Anyway, I suspect the real issue here is that when we build gcc to run

>>> on the target we currently configure using "--with-arch=armv7-a" for

>>> both armv7a and armv7ve. It was done that way deliberately to try to

>>> avoid rebuilds when switching between armv7a and armv7ve machines,

>>> although thinking about that now I'm not sure it makes so much sense.

>>> Does your original problem go away if you simply change:

>>>

>>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

>>>

>>> to

>>>

>>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

>>>

>>> in gcc-target.inc ?

>>

>> No, this is not the problem I am talking about gcc-runtime which is

>> configured during cross build but built for target later on.

>

> OK, good to rule that out. It's nothing to do with gcc8 and I've sent

> a separate patch to fix it.

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 7, 2018, 4:55 p.m. UTC | #8

On Wed, Jun 6, 2018 at 11:36 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Jun 06, 2018 at 10:58:19PM -0700, Khem Raj wrote:

>>

>>

>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>> > On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> >> On Wed, Jun 6, 2018 at 3:15 PM, Andre McCurdy <armccurdy@gmail.com> wrote:

>> >>> On Wed, Jun 6, 2018 at 2:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> >>>> -march option is already used to select the base architecture

>> >>>> therefore using -mcpu which infact will reset march+mtune can

>> >>>> cause conflicts,

>> >>>

>> >>> I think we need to at least understand how and why these conflicts

>> >>> have started to occur with gcc 8. The tuning files themselves don't

>> >>> contain any conflicts so the conflict must be coming from somewhere

>> >>> else. Do we know where?

>> >>

>> >> I explained it in previous emails as well, mcpu is a combination of march+mtune

>> >> how it reduces to these values depends on mcpu value. e.g. setting

>> >> mcpu=cortex-a7

>> >> would mean setting march=armv7ve and mtune to cortex-a7 internally

>> >> along with using code generator to use instructions available for that

>> >> cpu, thats why it errors out since it does not know which march to

>> >> use.

>> >> when we override one of these values on cmdline which we do then this can cause

>> >> the errors, these errors were happening before too see valgrind patch

>> >> its that gcc8 is catching more cases.

>> >

>> > The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>> > the same conflicts. It doesn't make sense that gcc8 is just catching

>> > more issues.

>>

>> It does make sense. the option parsing for these specific options on arm

>> have been revamped after gcc7, see

>>

>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>

>> >

>> > The valgrind case is not a good example. The conflict there comes

>> > because we leak CFLAGS intended for the target into Makefiles which

>> > valgrind uses to build test apps which are intended to only run under

>> > valgrind (ie NOT directly on the target). The real fix there would be

>> > to prevent the target specific flags being passed to build for those

>> > few valgrind test apps.

>> >

>>

>> it is manifesting similar conflicts

>>

>> >> example is gcc-runtime/libstdc++ which deducts arch flags based on

>> >> configure options

>> >> and we do not pass narrow mcpu option to it since we build SDKs which

>> >> do not target

>> >> just one particular sub-family of cpu but rather a sub arch

>> >> do not pass --with-cpu then it enforces some lowest common

>> >> denominator. When we say -mcpu then we

>> >> are actually asking the code to be generated for that particular CPU.

>> >

>> > If we are trying to build something which is reusable across multiple

>> > machines with the same architecture then it's a bug to be passing

>> > machine specific CFLAGS. Making the machine specific CFLAGS more

>> > generic is not the right solution.

>>

>> being reusable is a side-effect and a good one. Real problem is we are

>> not matching to what we say in package arches, Probably you are

>> confusing tunes to be meant for static code generation for a given CPU.

>> I am interested to hear more ideas to what would be right solution if

>> this is not it.

>

> I don't agree with this part, you're basically reverting the change from:

> http://git.openembedded.org/openembedded-core/commit/?id=f7bb2d4cf18ca8d2a90b4b3b5c6c48dad106ca28

> but since:

> http://git.openembedded.org/openembedded-core/commit/?id=cffda9a821a3b83a8529d643c567859e091c6846

> we already have different ARMPKGARCH for each DEFAULT_TUNE with

> different -mcpu option.

>

> If you want to target more generic configuration than you should use

> more generic DEFAULT_TUNE and even the default configuration will select

> something generic, e.g.:

> http://git.openembedded.org/openembedded-core/tree/meta/conf/machine/include/tune-cortexa8.inc

> sets

> DEFAULTTUNE ?= "armv7athf-neon"

> so no -mcpu options unless you explicitly ask for it by selecting

> more specific DEFAULT_TUNE in DISTRO config.


Indeed thats correct. Although it does not solve the problem at hand.
fundamental
contention is what tunes semantically should indicate. Currently, it is meaning
tune to generate code for that cpu subset, I am proposing to revert to
tuning the behaviour of
program for specific CPU while generating code for march.

I don't have data to prove one way is more optimized than other, but
both approached have
distribution merits, from past experience to specific tunes have
sometimes pessimized real world
workloads and limited single SDK's use to narrow set of machines.

Its clear we need to ignore -mcpu for gcc runtime since we want it to
be generic enough.
however I think we need to systematically remove setting any -mcpu for
it instead of just
addressing armv7ve case.

>

>> > Anyway, I suspect the real issue here is that when we build gcc to run

>> > on the target we currently configure using "--with-arch=armv7-a" for

>> > both armv7a and armv7ve. It was done that way deliberately to try to

>> > avoid rebuilds when switching between armv7a and armv7ve machines,

>> > although thinking about that now I'm not sure it makes so much sense.

>> > Does your original problem go away if you simply change:

>> >

>> >    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

>> >

>> > to

>> >

>> >    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"

>> >

>> > in gcc-target.inc ?

>>

>> No, this is not the problem I am talking about gcc-runtime which is

>> configured during cross build but built for target later on.

>>

>> talking about this case, changing --with-arch will make on device gcc

>> complain about mismatches with default runtime since it is meant to use

>> same runtime that will be built above.  Using armv7-a here is a

>> conscious choice.

>

> I've already tried this as well, because that's what I was doing long

> time ago with the tune files:

> http://git.openembedded.org/openembedded-core/commit/meta/conf/machine/include?id=35392025f3236f5e5393f9cf0857732da9a2e503

>

> but it's true that gcc-runtime is a bit more complicated by that, it

> doesn't use gcc-target.inc (gcc-target.inc is only used by gcc itself),

> so I've tried to move the --with-arch options a bit lower to

> gcc-configure-common.inc where we already set the archs for MIPS, but it

> didn't work well, at least as done in:

> https://pastebin.com/3Cc5MYBa

>

> and then I've moved to something else and never finished this one.

>

>>

>> >

>> >>>

>> >>> This patch is potentially going to hide bugs in cases where components

>> >>> try to provide their own CPU specific flags rather than fully

>> >>> respecting the flags set by OE. Generally we want to make those cases

>> >>> fail so that we can debug and fix them.

>> >>>

>> >>

>> >> No it wont. they can still do that. Last option wins so nothing changes there.

>> >

>> > The thing that changes is that after your patch, gcc will no longer

>> > report a conflict!

>> >

>> >> and in many cases it should be able to override specific flags for

>> >> specific packages

>> >> OE is a fall back for general default case.

>> >>

>> >> A good change this does is that code is targeted for bigger base arch

>> >> e.g. armv7-a

>> >> and not for cortex-a8 but its tuned to run better on cortex-a8 when we

>> >> use -mtune

>> >> it will still run on other armv7-a based CPUs, so right now when we

>> >> say our package

>> >> arch is arm7ve but then use -mcpu=cortex-a7 we are actually doing wrong thing

>> >> this should have meant package arch to be cortex-a7 as well. Now this

>> >> will be more

>> >> inline as well.

>> >>

>> >>

>> >>>> therefore setting just mtune here will ensure

>> >>>> that the code is optimized for the given tune as is the intention

>> >>>> of mcpu, however with one advantage, it will be targetting broader

>> >>>> march value so can be useful for pre-compiled objects where they

>> >>>> can be run on wider subset

>> >>>>

>> >>>> This also fixed occasional conflicts like

>> >>>>

>> >>>> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch [-Werror]

>> >>>>

>> >>>> which is possible combination in some case for packages in OE

>> >>>>

>> >>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

>> >>>> ---

>> >>>>   meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-

>> >>>>   meta/conf/machine/include/tune-arm920t.inc       | 2 +-

>> >>>>   meta/conf/machine/include/tune-arm926ejs.inc     | 2 +-

>> >>>>   meta/conf/machine/include/tune-arm9tdmi.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa15.inc     | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa17.inc     | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa5.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa7.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa8.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-cortexa9.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-ep9312.inc        | 2 +-

>> >>>>   meta/conf/machine/include/tune-iwmmxt.inc        | 2 +-

>> >>>>   meta/conf/machine/include/tune-strongarm1100.inc | 2 +-

>> >>>>   meta/conf/machine/include/tune-thunderx.inc      | 2 +-

>> >>>>   meta/conf/machine/include/tune-xscale.inc        | 2 +-

>> >>>>   15 files changed, 15 insertions(+), 15 deletions(-)

>> >>>>

>> >>>> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc

>> >>>> index c5de63e1cc..02114284e0 100644

>> >>>> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc

>> >>>> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6hf"

>> >>>>   require conf/machine/include/arm/arch-armv6.inc

>> >>>>

>> >>>>   TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mcpu=arm1136jf-s', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' -mtune=arm1136jf-s', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "arm1136jfs"

>> >>>>   ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

>> >>>> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc

>> >>>> index c6e74b6772..5e6d4cbd91 100644

>> >>>> --- a/meta/conf/machine/include/tune-arm920t.inc

>> >>>> +++ b/meta/conf/machine/include/tune-arm920t.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>> >>>>   require conf/machine/include/arm/arch-armv4.inc

>> >>>>

>> >>>>   TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mcpu=arm920t', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' -mtune=arm920t', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "arm920t"

>> >>>>   ARMPKGARCH_tune-arm920t = "arm920t"

>> >>>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc

>> >>>> index 81bcda339b..dddccaaae9 100644

>> >>>> --- a/meta/conf/machine/include/tune-arm926ejs.inc

>> >>>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>> >>>>

>> >>>>   TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mcpu=arm926ej-s', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' -mtune=arm926ej-s', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "arm926ejs"

>> >>>>   ARMPKGARCH_tune-arm926ejs = "arm926ejs"

>> >>>> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc

>> >>>> index e9c2b8fcf5..ebac472c5b 100644

>> >>>> --- a/meta/conf/machine/include/tune-arm9tdmi.inc

>> >>>> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"

>> >>>>   require conf/machine/include/arm/arch-armv4.inc

>> >>>>

>> >>>>   TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mcpu=arm9tdmi', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' -mtune=arm9tdmi', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "arm9tdmi"

>> >>>>   ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa15.inc b/meta/conf/machine/include/tune-cortexa15.inc

>> >>>> index 25e99f93d7..0636306e2f 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa15.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa15.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mcpu=cortex-a15', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa15', ' -mtune=cortex-a15', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon cortexa15-neon-vfpv4 cortexa15t-neon-vfpv4"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa17.inc b/meta/conf/machine/include/tune-cortexa17.inc

>> >>>> index 40392f9bcc..f9774b8b8e 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa17.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa17.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mcpu=cortex-a17', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' -mtune=cortex-a17', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa17 cortexa17t cortexa17-neon cortexa17t-neon cortexa17-neon-vfpv4 cortexa17t-neon-vfpv4"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa5.inc b/meta/conf/machine/include/tune-cortexa5.inc

>> >>>> index 1f0cda6640..1ececf9621 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa5.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa5.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7a.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa5] = "Enable Cortex-A5 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mcpu=cortex-a5', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa5', ' -mtune=cortex-a5', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa5 cortexa5t cortexa5-neon cortexa5t-neon"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa7.inc b/meta/conf/machine/include/tune-cortexa7.inc

>> >>>> index 52415d9c8b..08dd039338 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa7.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa7.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7vethf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7ve.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mcpu=cortex-a7', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa7', ' -mtune=cortex-a7', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon cortexa7-neon-vfpv4 cortexa7t-neon-vfpv4"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc

>> >>>> index 8ee8de97f1..cdcb1c7d59 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa8.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa8.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7a.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mcpu=cortex-a8', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa8', ' -mtune=cortex-a8', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

>> >>>> diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc

>> >>>> index 0cf323c960..620178d18a 100644

>> >>>> --- a/meta/conf/machine/include/tune-cortexa9.inc

>> >>>> +++ b/meta/conf/machine/include/tune-cortexa9.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7athf-neon"

>> >>>>   require conf/machine/include/arm/arch-armv7a.inc

>> >>>>

>> >>>>   TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mcpu=cortex-a9', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', ' -mtune=cortex-a9', '', d)}"

>> >>>>

>> >>>>   # Little Endian base configs

>> >>>>   AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

>> >>>> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc

>> >>>> index 84ca528d6d..897b904cd1 100644

>> >>>> --- a/meta/conf/machine/include/tune-ep9312.inc

>> >>>> +++ b/meta/conf/machine/include/tune-ep9312.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "ep9312"

>> >>>>   require conf/machine/include/arm/arch-armv4.inc

>> >>>>

>> >>>>   TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mcpu=ep9312', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'ep9312', ' -march=ep9312 -mtune=ep9312', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "ep9312"

>> >>>>   ARMPKGARCH_tune-ep9312 = "ep9312"

>> >>>> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc

>> >>>> index f27423cb2e..15cce8d3c5 100644

>> >>>> --- a/meta/conf/machine/include/tune-iwmmxt.inc

>> >>>> +++ b/meta/conf/machine/include/tune-iwmmxt.inc

>> >>>> @@ -6,7 +6,7 @@ DEFAULTTUNE ?= "iwmmxt"

>> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>> >>>>

>> >>>>   TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mcpu=iwmmxt', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'iwmmxt', ' -march=iwmmxt -mtune=iwmmxt', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "iwmmxt"

>> >>>>   ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>> >>>> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc

>> >>>> index 80cfb8ab8a..7b2fa8e3ab 100644

>> >>>> --- a/meta/conf/machine/include/tune-strongarm1100.inc

>> >>>> +++ b/meta/conf/machine/include/tune-strongarm1100.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4"

>> >>>>   require conf/machine/include/arm/arch-armv4.inc

>> >>>>

>> >>>>   TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "strongarm"

>> >>>>   ARMPKGARCH_tune-strongarm = "strongarm"

>> >>>> diff --git a/meta/conf/machine/include/tune-thunderx.inc b/meta/conf/machine/include/tune-thunderx.inc

>> >>>> index 3d43b0f7e5..e77d1cdd2d 100644

>> >>>> --- a/meta/conf/machine/include/tune-thunderx.inc

>> >>>> +++ b/meta/conf/machine/include/tune-thunderx.inc

>> >>>> @@ -5,7 +5,7 @@ AVAILTUNES += "thunderx thunderx_be"

>> >>>>

>> >>>>   TUNEVALID[thunderx] = "Enable instructions for Cavium ThunderX"

>> >>>>

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mcpu=thunderx ', '',d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'thunderx', ' -mtune=thunderx ', '',d)}"

>> >>>>

>> >>>>   ARMPKGARCH_tune-thunderx ?= "thunderx"

>> >>>>   ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"

>> >>>> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc

>> >>>> index 0d07333955..2a0610fddf 100644

>> >>>> --- a/meta/conf/machine/include/tune-xscale.inc

>> >>>> +++ b/meta/conf/machine/include/tune-xscale.inc

>> >>>> @@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"

>> >>>>   require conf/machine/include/arm/arch-armv5-dsp.inc

>> >>>>

>> >>>>   TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"

>> >>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mcpu=xscale', '', d)}"

>> >>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'xscale', ' -mtune=xscale', '', d)}"

>> >>>>

>> >>>>   AVAILTUNES += "xscale"

>> >>>>   ARMPKGARCH_tune-xscale = "xscale"

>> >>>> --

>> >>>> 2.17.1

>> >>>>

>> >>>> --

>> >>>> _______________________________________________

>> >>>> Openembedded-core mailing list

>> >>>> Openembedded-core@lists.openembedded.org

>> >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

>> --

>> _______________________________________________

>> Openembedded-core mailing list

>> Openembedded-core@lists.openembedded.org

>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

>

> --

> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy June 7, 2018, 11:38 p.m. UTC | #9

On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com> wrote:

>> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>

>>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>>> more issues.

>>>

>>> It does make sense. the option parsing for these specific options on arm

>>> have been revamped after gcc7, see

>>>

>>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>

>> Thanks. These commits seem to be related to handling of options like

>> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>>

>> If you can provide the command line that caused the error then it

>> should be quick to establish whether it's gcc8 being more picky.

>>

>> Or perhaps there's always been a warning and -Werror has been added to

>> a gcc8 Makefile where it wasn't before?

>>

>>>> If we are trying to build something which is reusable across multiple

>>>> machines with the same architecture then it's a bug to be passing

>>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>>> generic is not the right solution.

>>>

>>> being reusable is a side-effect and a good one. Real problem is we are not

>>> matching to what we say in package arches, Probably you are confusing tunes

>>> to be meant for static code generation for a given CPU.

>>

>> Sorry, I don't really follow what you mean?

>>

>>> I am interested to

>>> hear more ideas to what would be right solution if this is not it.

>>

>> I'd like to understand what the problem is first before trying to

>> propose any solutions.

>>

>> ie what specifically has changed with gcc8 to cause the error which

>> wasn't seen before?

>

> I would suggest take this gcc8 patch series and revert this one then build

> gcc-runtime for rpi3

That's the answer to "how do I reproduce the issue" not to "what is the issue".

Anyway, I can reproduce the issue. The root cause is that gcc-runtime
libatomic tries to support runtime selection between different
implementations of a few low level functions by making use of the gcc
"ifunc" function attribute:

  https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

ie libatomic can contain versions of functions specific to armv6 or
armv7 with selection between them being made at runtime via ifunc.

In order to build the armv7 versions of these few functions, the
libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This
isn't new - it goes back to at least 2012 in gcc git history.

  https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html

What _is_ new is that for ARM, support for ifunc function attributes
was not enabled prior to gcc8. ie when building with gcc7, the
libatomic configure script determines that the toolchain doesn't
support ifunc and libatomic therefore builds without support for
runtime function selection... since it never needs to compile armv7
specific versions of the runtime selectable functions the -march -vs-
-mcpu conflict never happens.

  https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html

(Note that ifunc support for ARM in gcc8 is still only enabled for
glibc, so this issue doesn't show up at all with musl).

Various solutions are possible:

1) Let libatomic continue to build with ifunc support enabled, but
avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in
the gcc-runtime recipe.

2) Let libatomic continue to build with ifunc support enabled, but
avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles
so that they always safely over-ride any combination of -march, -mcpu,
etc passed in from the build environment. ie patch the libatomic
Makefiles to replace:

  IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64

with:

  IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64

(Regardless of the solution we pick for OE, I think that fix should be
submitted upstream to libatomic. There's no need for libatomic to risk
build errors by not defining -mcpu in cases where it specifically
wants to target armv7a).

3) Prevent libatomic from building with ifunc support enabled for ARM
by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe.

Votes?
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 8, 2018, 12:57 a.m. UTC | #10

On 6/7/18 4:38 PM, Andre McCurdy wrote:
> On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj <raj.khem@gmail.com> wrote:

>> On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com> wrote:

>>> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>

>>>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>>>> more issues.

>>>>

>>>> It does make sense. the option parsing for these specific options on arm

>>>> have been revamped after gcc7, see

>>>>

>>>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>>

>>> Thanks. These commits seem to be related to handling of options like

>>> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>>>

>>> If you can provide the command line that caused the error then it

>>> should be quick to establish whether it's gcc8 being more picky.

>>>

>>> Or perhaps there's always been a warning and -Werror has been added to

>>> a gcc8 Makefile where it wasn't before?

>>>

>>>>> If we are trying to build something which is reusable across multiple

>>>>> machines with the same architecture then it's a bug to be passing

>>>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>>>> generic is not the right solution.

>>>>

>>>> being reusable is a side-effect and a good one. Real problem is we are not

>>>> matching to what we say in package arches, Probably you are confusing tunes

>>>> to be meant for static code generation for a given CPU.

>>>

>>> Sorry, I don't really follow what you mean?

>>>

>>>> I am interested to

>>>> hear more ideas to what would be right solution if this is not it.

>>>

>>> I'd like to understand what the problem is first before trying to

>>> propose any solutions.

>>>

>>> ie what specifically has changed with gcc8 to cause the error which

>>> wasn't seen before?

>>

>> I would suggest take this gcc8 patch series and revert this one then build

>> gcc-runtime for rpi3

> 

> That's the answer to "how do I reproduce the issue" not to "what is the issue".

> 


another way to nudge for some help :) Thanks for digging further details.

> Anyway, I can reproduce the issue. The root cause is that gcc-runtime

> libatomic tries to support runtime selection between different

> implementations of a few low level functions by making use of the gcc

> "ifunc" function attribute:

> 

>    https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

> 

> ie libatomic can contain versions of functions specific to armv6 or

> armv7 with selection between them being made at runtime via ifunc.

> 

> In order to build the armv7 versions of these few functions, the

> libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This

> isn't new - it goes back to at least 2012 in gcc git history.

> 

>    https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html

> 

> What _is_ new is that for ARM, support for ifunc function attributes

> was not enabled prior to gcc8. ie when building with gcc7, the

> libatomic configure script determines that the toolchain doesn't

> support ifunc and libatomic therefore builds without support for

> runtime function selection... since it never needs to compile armv7

> specific versions of the runtime selectable functions the -march -vs-

> -mcpu conflict never happens.

> 

>    https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html

> 

> (Note that ifunc support for ARM in gcc8 is still only enabled for

> glibc, so this issue doesn't show up at all with musl).

> 

> Various solutions are possible:

> 

> 1) Let libatomic continue to build with ifunc support enabled, but

> avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in

> the gcc-runtime recipe.


I don't think this is required. Even though it might be useful for other 
reasons.

> 

> 2) Let libatomic continue to build with ifunc support enabled, but

> avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles

> so that they always safely over-ride any combination of -march, -mcpu,

> etc passed in from the build environment. ie patch the libatomic

> Makefiles to replace:

> 

>    IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64

> 

> with:

> 

>    IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64

> 

> (Regardless of the solution we pick for OE, I think that fix should be

> submitted upstream to libatomic. There's no need for libatomic to risk

> build errors by not defining -mcpu in cases where it specifically

> wants to target armv7a).


I think this is better. Now my memory serves me right I had a local 
patch few months ago which I discarded where I was using -march with 
armv7ve but it was limiting for other reasons. I think it would be 
better to drop -march completely.

IFUNC_OPTIONS = -mcpu=generic-armv7-a -DHAVE_KERNEL64

I will test it out locally and see if that works.

> 

> 3) Prevent libatomic from building with ifunc support enabled for ARM

> by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe.

> 


This would be ok too for OE ifuncs dont serve much since we target a 
specific CPU anyway.

> Votes?

> 


approach 2 is what we should use.


-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Andre McCurdy June 8, 2018, 1:20 a.m. UTC | #11

On Thu, Jun 7, 2018 at 5:57 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On 6/7/18 4:38 PM, Andre McCurdy wrote:

>> On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj <raj.khem@gmail.com> wrote:

>>> On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com>

>>> wrote:

>>>> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>>>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>>

>>>>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>>>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>>>>> more issues.

>>>>>

>>>>> It does make sense. the option parsing for these specific options on

>>>>> arm

>>>>> have been revamped after gcc7, see

>>>>>

>>>>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>>>

>>>> Thanks. These commits seem to be related to handling of options like

>>>> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>>>>

>>>> If you can provide the command line that caused the error then it

>>>> should be quick to establish whether it's gcc8 being more picky.

>>>>

>>>> Or perhaps there's always been a warning and -Werror has been added to

>>>> a gcc8 Makefile where it wasn't before?

>>>>

>>>>>> If we are trying to build something which is reusable across multiple

>>>>>> machines with the same architecture then it's a bug to be passing

>>>>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>>>>> generic is not the right solution.

>>>>>

>>>>> being reusable is a side-effect and a good one. Real problem is we are

>>>>> not

>>>>> matching to what we say in package arches, Probably you are confusing

>>>>> tunes

>>>>> to be meant for static code generation for a given CPU.

>>>>

>>>> Sorry, I don't really follow what you mean?

>>>>

>>>>> I am interested to

>>>>> hear more ideas to what would be right solution if this is not it.

>>>>

>>>> I'd like to understand what the problem is first before trying to

>>>> propose any solutions.

>>>>

>>>> ie what specifically has changed with gcc8 to cause the error which

>>>> wasn't seen before?

>>>

>>> I would suggest take this gcc8 patch series and revert this one then

>>> build

>>> gcc-runtime for rpi3

>>

>> That's the answer to "how do I reproduce the issue" not to "what is the

>> issue".

>

> another way to nudge for some help :) Thanks for digging further details.

>

>> Anyway, I can reproduce the issue. The root cause is that gcc-runtime

>> libatomic tries to support runtime selection between different

>> implementations of a few low level functions by making use of the gcc

>> "ifunc" function attribute:

>>

>> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

>>

>> ie libatomic can contain versions of functions specific to armv6 or

>> armv7 with selection between them being made at runtime via ifunc.

>>

>> In order to build the armv7 versions of these few functions, the

>> libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This

>> isn't new - it goes back to at least 2012 in gcc git history.

>>

>>    https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html

>>

>> What _is_ new is that for ARM, support for ifunc function attributes

>> was not enabled prior to gcc8. ie when building with gcc7, the

>> libatomic configure script determines that the toolchain doesn't

>> support ifunc and libatomic therefore builds without support for

>> runtime function selection... since it never needs to compile armv7

>> specific versions of the runtime selectable functions the -march -vs-

>> -mcpu conflict never happens.

>>

>>    https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html

>>

>> (Note that ifunc support for ARM in gcc8 is still only enabled for

>> glibc, so this issue doesn't show up at all with musl).

>>

>> Various solutions are possible:

>>

>> 1) Let libatomic continue to build with ifunc support enabled, but

>> avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in

>> the gcc-runtime recipe.

>

> I don't think this is required. Even though it might be useful for other

> reasons.

>

>> 2) Let libatomic continue to build with ifunc support enabled, but

>> avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles

>> so that they always safely over-ride any combination of -march, -mcpu,

>> etc passed in from the build environment. ie patch the libatomic

>> Makefiles to replace:

>>

>>    IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64

>>

>> with:

>>

>>    IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64

>>

>> (Regardless of the solution we pick for OE, I think that fix should be

>> submitted upstream to libatomic. There's no need for libatomic to risk

>> build errors by not defining -mcpu in cases where it specifically

>> wants to target armv7a).

>

> I think this is better. Now my memory serves me right I had a local patch

> few months ago which I discarded where I was using -march with armv7ve but

> it was limiting for other reasons. I think it would be better to drop -march

> completely.

>

> IFUNC_OPTIONS = -mcpu=generic-armv7-a -DHAVE_KERNEL64

>

> I will test it out locally and see if that works.


If you only set -mcpu then you're likely to run into issues when
-march is set externally to something incompatible.

>> 3) Prevent libatomic from building with ifunc support enabled for ARM

>> by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe.

>

> This would be ok too for OE ifuncs dont serve much since we target a

> specific CPU anyway.


Right. This is the one I'd vote for. For ARM there's little point
including runtime alternatives when we always compile everything in
rootfs for one particular target architecture level anyway.
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 8, 2018, 1:48 a.m. UTC | #12

On 6/7/18 6:20 PM, Andre McCurdy wrote:
> On Thu, Jun 7, 2018 at 5:57 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> On 6/7/18 4:38 PM, Andre McCurdy wrote:

>>> On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj <raj.khem@gmail.com> wrote:

>>>> On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com>

>>>> wrote:

>>>>> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>>>>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>>>

>>>>>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>>>>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>>>>>> more issues.

>>>>>>

>>>>>> It does make sense. the option parsing for these specific options on

>>>>>> arm

>>>>>> have been revamped after gcc7, see

>>>>>>

>>>>>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>>>>

>>>>> Thanks. These commits seem to be related to handling of options like

>>>>> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>>>>>

>>>>> If you can provide the command line that caused the error then it

>>>>> should be quick to establish whether it's gcc8 being more picky.

>>>>>

>>>>> Or perhaps there's always been a warning and -Werror has been added to

>>>>> a gcc8 Makefile where it wasn't before?

>>>>>

>>>>>>> If we are trying to build something which is reusable across multiple

>>>>>>> machines with the same architecture then it's a bug to be passing

>>>>>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>>>>>> generic is not the right solution.

>>>>>>

>>>>>> being reusable is a side-effect and a good one. Real problem is we are

>>>>>> not

>>>>>> matching to what we say in package arches, Probably you are confusing

>>>>>> tunes

>>>>>> to be meant for static code generation for a given CPU.

>>>>>

>>>>> Sorry, I don't really follow what you mean?

>>>>>

>>>>>> I am interested to

>>>>>> hear more ideas to what would be right solution if this is not it.

>>>>>

>>>>> I'd like to understand what the problem is first before trying to

>>>>> propose any solutions.

>>>>>

>>>>> ie what specifically has changed with gcc8 to cause the error which

>>>>> wasn't seen before?

>>>>

>>>> I would suggest take this gcc8 patch series and revert this one then

>>>> build

>>>> gcc-runtime for rpi3

>>>

>>> That's the answer to "how do I reproduce the issue" not to "what is the

>>> issue".

>>

>> another way to nudge for some help :) Thanks for digging further details.

>>

>>> Anyway, I can reproduce the issue. The root cause is that gcc-runtime

>>> libatomic tries to support runtime selection between different

>>> implementations of a few low level functions by making use of the gcc

>>> "ifunc" function attribute:

>>>

>>> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

>>>

>>> ie libatomic can contain versions of functions specific to armv6 or

>>> armv7 with selection between them being made at runtime via ifunc.

>>>

>>> In order to build the armv7 versions of these few functions, the

>>> libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This

>>> isn't new - it goes back to at least 2012 in gcc git history.

>>>

>>>     https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html

>>>

>>> What _is_ new is that for ARM, support for ifunc function attributes

>>> was not enabled prior to gcc8. ie when building with gcc7, the

>>> libatomic configure script determines that the toolchain doesn't

>>> support ifunc and libatomic therefore builds without support for

>>> runtime function selection... since it never needs to compile armv7

>>> specific versions of the runtime selectable functions the -march -vs-

>>> -mcpu conflict never happens.

>>>

>>>     https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html

>>>

>>> (Note that ifunc support for ARM in gcc8 is still only enabled for

>>> glibc, so this issue doesn't show up at all with musl).

>>>

>>> Various solutions are possible:

>>>

>>> 1) Let libatomic continue to build with ifunc support enabled, but

>>> avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in

>>> the gcc-runtime recipe.

>>

>> I don't think this is required. Even though it might be useful for other

>> reasons.

>>

>>> 2) Let libatomic continue to build with ifunc support enabled, but

>>> avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles

>>> so that they always safely over-ride any combination of -march, -mcpu,

>>> etc passed in from the build environment. ie patch the libatomic

>>> Makefiles to replace:

>>>

>>>     IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64

>>>

>>> with:

>>>

>>>     IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64

>>>

>>> (Regardless of the solution we pick for OE, I think that fix should be

>>> submitted upstream to libatomic. There's no need for libatomic to risk

>>> build errors by not defining -mcpu in cases where it specifically

>>> wants to target armv7a).

>>

>> I think this is better. Now my memory serves me right I had a local patch

>> few months ago which I discarded where I was using -march with armv7ve but

>> it was limiting for other reasons. I think it would be better to drop -march

>> completely.

>>

>> IFUNC_OPTIONS = -mcpu=generic-armv7-a -DHAVE_KERNEL64

>>

>> I will test it out locally and see if that works.

> 

> If you only set -mcpu then you're likely to run into issues when

> -march is set externally to something incompatible.


yes that is right.

> 

>>> 3) Prevent libatomic from building with ifunc support enabled for ARM

>>> by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe.

>>

>> This would be ok too for OE ifuncs dont serve much since we target a

>> specific CPU anyway.

> 

> Right. This is the one I'd vote for. For ARM there's little point

> including runtime alternatives when we always compile everything in

> rootfs for one particular target architecture level anyway.

> 


I think we can have both 2 and 3 where 2 is more upstreamworthy and 3 we 
can keep for OE
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj June 8, 2018, 8:12 a.m. UTC | #13

On 6/7/18 6:20 PM, Andre McCurdy wrote:
> On Thu, Jun 7, 2018 at 5:57 PM, Khem Raj <raj.khem@gmail.com> wrote:

>> On 6/7/18 4:38 PM, Andre McCurdy wrote:

>>> On Thu, Jun 7, 2018 at 7:04 AM, Khem Raj <raj.khem@gmail.com> wrote:

>>>> On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy@gmail.com>

>>>> wrote:

>>>>> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>> On 6/6/18 4:42 PM, Andre McCurdy wrote:

>>>>>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem@gmail.com> wrote:

>>>>>>>

>>>>>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch

>>>>>>> the same conflicts. It doesn't make sense that gcc8 is just catching

>>>>>>> more issues.

>>>>>>

>>>>>> It does make sense. the option parsing for these specific options on

>>>>>> arm

>>>>>> have been revamped after gcc7, see

>>>>>>

>>>>>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7

>>>>>

>>>>> Thanks. These commits seem to be related to handling of options like

>>>>> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?

>>>>>

>>>>> If you can provide the command line that caused the error then it

>>>>> should be quick to establish whether it's gcc8 being more picky.

>>>>>

>>>>> Or perhaps there's always been a warning and -Werror has been added to

>>>>> a gcc8 Makefile where it wasn't before?

>>>>>

>>>>>>> If we are trying to build something which is reusable across multiple

>>>>>>> machines with the same architecture then it's a bug to be passing

>>>>>>> machine specific CFLAGS. Making the machine specific CFLAGS more

>>>>>>> generic is not the right solution.

>>>>>>

>>>>>> being reusable is a side-effect and a good one. Real problem is we are

>>>>>> not

>>>>>> matching to what we say in package arches, Probably you are confusing

>>>>>> tunes

>>>>>> to be meant for static code generation for a given CPU.

>>>>>

>>>>> Sorry, I don't really follow what you mean?

>>>>>

>>>>>> I am interested to

>>>>>> hear more ideas to what would be right solution if this is not it.

>>>>>

>>>>> I'd like to understand what the problem is first before trying to

>>>>> propose any solutions.

>>>>>

>>>>> ie what specifically has changed with gcc8 to cause the error which

>>>>> wasn't seen before?

>>>>

>>>> I would suggest take this gcc8 patch series and revert this one then

>>>> build

>>>> gcc-runtime for rpi3

>>>

>>> That's the answer to "how do I reproduce the issue" not to "what is the

>>> issue".

>>

>> another way to nudge for some help :) Thanks for digging further details.

>>

>>> Anyway, I can reproduce the issue. The root cause is that gcc-runtime

>>> libatomic tries to support runtime selection between different

>>> implementations of a few low level functions by making use of the gcc

>>> "ifunc" function attribute:

>>>

>>> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

>>>

>>> ie libatomic can contain versions of functions specific to armv6 or

>>> armv7 with selection between them being made at runtime via ifunc.

>>>

>>> In order to build the armv7 versions of these few functions, the

>>> libatomic Makefiles selectively add -march=armv7-a to CFLAGS. This

>>> isn't new - it goes back to at least 2012 in gcc git history.

>>>

>>>     https://gcc.gnu.org/ml/gcc/2014-01/msg00141.html

>>>

>>> What _is_ new is that for ARM, support for ifunc function attributes

>>> was not enabled prior to gcc8. ie when building with gcc7, the

>>> libatomic configure script determines that the toolchain doesn't

>>> support ifunc and libatomic therefore builds without support for

>>> runtime function selection... since it never needs to compile armv7

>>> specific versions of the runtime selectable functions the -march -vs-

>>> -mcpu conflict never happens.

>>>

>>>     https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00521.html

>>>

>>> (Note that ifunc support for ARM in gcc8 is still only enabled for

>>> glibc, so this issue doesn't show up at all with musl).

>>>

>>> Various solutions are possible:

>>>

>>> 1) Let libatomic continue to build with ifunc support enabled, but

>>> avoid -march -vs- mcpu conflicts by dropping -mcpu from OE's CFLAGS in

>>> the gcc-runtime recipe.

>>

>> I don't think this is required. Even though it might be useful for other

>> reasons.

>>

>>> 2) Let libatomic continue to build with ifunc support enabled, but

>>> avoid -march -vs- -mcpu conflicts by updating the libatomic Makefiles

>>> so that they always safely over-ride any combination of -march, -mcpu,

>>> etc passed in from the build environment. ie patch the libatomic

>>> Makefiles to replace:

>>>

>>>     IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64

>>>

>>> with:

>>>

>>>     IFUNC_OPTIONS = -march=armv7-a+fp -mcpu=generic-armv7-a -DHAVE_KERNEL64

>>>

>>> (Regardless of the solution we pick for OE, I think that fix should be

>>> submitted upstream to libatomic. There's no need for libatomic to risk

>>> build errors by not defining -mcpu in cases where it specifically

>>> wants to target armv7a).

>>

>> I think this is better. Now my memory serves me right I had a local patch

>> few months ago which I discarded where I was using -march with armv7ve but

>> it was limiting for other reasons. I think it would be better to drop -march

>> completely.

>>

>> IFUNC_OPTIONS = -mcpu=generic-armv7-a -DHAVE_KERNEL64

>>

>> I will test it out locally and see if that works.

> 

> If you only set -mcpu then you're likely to run into issues when

> -march is set externally to something incompatible.


this actually is not a normal append but it actually build for each of 
options so adding -mcpu here wont work for the issue at hand. It will
mean this is an additional build

> 

>>> 3) Prevent libatomic from building with ifunc support enabled for ARM

>>> by forcing "libat_cv_have_ifunc=no" from the gcc-runtime recipe.

>>

>> This would be ok too for OE ifuncs dont serve much since we target a

>> specific CPU anyway.

> 

> Right. This is the one I'd vote for. For ARM there's little point

> including runtime alternatives when we always compile everything in

> rootfs for one particular target architecture level anyway.

> 


So this is our best bet. I have taken this into v3 of patchset.
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[01/12] tune/arm: Set -mtune instead of -mcpu

Commit Message

Comments

Patch