arch-arm: Do not add -march options for arm architecture

Message ID 20190123200520.14956-1-raj.khem@gmail.com
State New
Headers show
Series
  • arch-arm: Do not add -march options for arm architecture
Related show

Commit Message

Khem Raj Jan. 23, 2019, 8:05 p.m.
tune files which inherit the arch definitions already define appropriate
-mcpu option, which is equivalent of right -march and -mtune combination
and is preferred since gcc is getting stricter and stricter with option
check semantics and can now find incompatible -march and -mcpu options
better with every release. It does internal feature consistency check
and if it finds out discrepency between what -mcpu would expand to as
compared to -march it will flag the options to be incompatible, for
naked eye it sounds wrong but gcc would translate -mcpu to a given
-march internally and it might not match to what we set in these arch
files.

The effects are quite subtle, where this can result in configure test
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ ends up
disabled due to configure check failures e.g. size_t size, ptrdiff_t
sizes, which inturn results in compiling libstdc++ with unwanted
disabled features.

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

---
 meta/conf/machine/include/arm/arch-armv4.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv5.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv6.inc   | 1 -
 meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -
 meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -
 meta/conf/machine/include/tune-iwmmxt.inc      | 2 +-
 6 files changed, 1 insertion(+), 6 deletions(-)

-- 
2.20.1

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

Comments

Andre McCurdy Jan. 23, 2019, 10:27 p.m. | #1
On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:
>

> tune files which inherit the arch definitions already define appropriate

> -mcpu option, which is equivalent of right -march and -mtune combination


And what about machines which inherit an arch definition instead of a
cpu definition? Is that no longer supported?

> and is preferred since gcc is getting stricter and stricter with option

> check semantics and can now find incompatible -march and -mcpu options

> better with every release. It does internal feature consistency check

> and if it finds out discrepency between what -mcpu would expand to as

> compared to -march it will flag the options to be incompatible, for

> naked eye it sounds wrong but gcc would translate -mcpu to a given

> -march internally and it might not match to what we set in these arch

> files.

>

> The effects are quite subtle, where this can result in configure test

> failing to compile due to these incompatible options and a feature

> option getting disabled for a recipe for no reason.

>

> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> -march=armv7-a are incompatible, many features in libstdc++ ends up

> disabled due to configure check failures e.g. size_t size, ptrdiff_t

> sizes, which inturn results in compiling libstdc++ with unwanted

> disabled features.


It would be interesting to see more specific details of this.

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

> ---

>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

>  6 files changed, 1 insertion(+), 6 deletions(-)

>

> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

> index 47a7ad2830..52d8ab1e8f 100644

> --- a/meta/conf/machine/include/arm/arch-armv4.inc

> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

>

>  TUNEVALID[arm] = "Enable ARM instruction set"

>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

>  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

>  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

> index f9068af9de..1fe1b6b8e4 100644

> --- a/meta/conf/machine/include/arm/arch-armv5.inc

> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

>

>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

>  TUNECONFLICTS[armv5] = "armv4"

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

>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

>

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

> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

> index 6c838e999c..adb9be8050 100644

> --- a/meta/conf/machine/include/arm/arch-armv6.inc

> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

>

>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

>  TUNECONFLICTS[armv6] = "armv4 armv5"

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

>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

>

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

> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

> index a2663d8008..09d2c03a5d 100644

> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

>

>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

>

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

> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

> index 4d9260fecb..31e334f645 100644

> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

>

>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

>

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

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

> index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

>

>  AVAILTUNES += "iwmmxt"

>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> --

> 2.20.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 Jan. 23, 2019, 10:50 p.m. | #2
On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:
>

> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

> >

> > tune files which inherit the arch definitions already define appropriate

> > -mcpu option, which is equivalent of right -march and -mtune combination

>

> And what about machines which inherit an arch definition instead of a

> cpu definition? Is that no longer supported?


I could not find such a machine configuration in several BSP layers I looked at.
Do you know of machine definitions where these files are included
directly in machine configs ?
if so, then we have to either use _remove or introduce a weak variable
to set march only if
mcpu is not set which

>

> > and is preferred since gcc is getting stricter and stricter with option

> > check semantics and can now find incompatible -march and -mcpu options

> > better with every release. It does internal feature consistency check

> > and if it finds out discrepency between what -mcpu would expand to as

> > compared to -march it will flag the options to be incompatible, for

> > naked eye it sounds wrong but gcc would translate -mcpu to a given

> > -march internally and it might not match to what we set in these arch

> > files.

> >

> > The effects are quite subtle, where this can result in configure test

> > failing to compile due to these incompatible options and a feature

> > option getting disabled for a recipe for no reason.

> >

> > e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> > -march=armv7-a are incompatible, many features in libstdc++ ends up

> > disabled due to configure check failures e.g. size_t size, ptrdiff_t

> > sizes, which inturn results in compiling libstdc++ with unwanted

> > disabled features.

>

> It would be interesting to see more specific details of this.


These are configure tests which fail when -Werror is in use and is not
limited to libstdc++
it can happen in any package. Since the diagnostic about incompatible
march mcpu pair
is a warning in general, it does not matter, but when we have -Werror
enabled this turns
into error, You can simply try a small helloworld example to see the effects.

>

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

> > ---

> >  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> >  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> >  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> >  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> >  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> >  6 files changed, 1 insertion(+), 6 deletions(-)

> >

> > diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

> > index 47a7ad2830..52d8ab1e8f 100644

> > --- a/meta/conf/machine/include/arm/arch-armv4.inc

> > +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> >

> >  TUNEVALID[arm] = "Enable ARM instruction set"

> >  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

> >  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

> >  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

> >  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

> > diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

> > index f9068af9de..1fe1b6b8e4 100644

> > --- a/meta/conf/machine/include/arm/arch-armv5.inc

> > +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> >

> >  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> >  TUNECONFLICTS[armv5] = "armv4"

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

> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

> >

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

> > diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

> > index 6c838e999c..adb9be8050 100644

> > --- a/meta/conf/machine/include/arm/arch-armv6.inc

> > +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> >

> >  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> >  TUNECONFLICTS[armv6] = "armv4 armv5"

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

> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

> >

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

> > diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

> > index a2663d8008..09d2c03a5d 100644

> > --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> > +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> > @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> >

> >  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> >  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

> >

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

> > diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > index 4d9260fecb..31e334f645 100644

> > --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> > +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> >

> >  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> >  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

> >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

> >

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

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

> > index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

> >

> >  AVAILTUNES += "iwmmxt"

> >  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> > --

> > 2.20.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 Jan. 23, 2019, 11:11 p.m. | #3
On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:
>

> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:

> >

> > On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

> > >

> > > tune files which inherit the arch definitions already define appropriate

> > > -mcpu option, which is equivalent of right -march and -mtune combination

> >

> > And what about machines which inherit an arch definition instead of a

> > cpu definition? Is that no longer supported?

>

> I could not find such a machine configuration in several BSP layers I looked at.

> Do you know of machine definitions where these files are included

> directly in machine configs ?


Using a CPU specific include but then leaving the generic DEFAULTTUNE
(ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I
guess quite common.

> if so, then we have to either use _remove or introduce a weak variable

> to set march only if

> mcpu is not set which


I think the solution is to ensure that the CPU specific tuning options
are always compatible with any architecture specific options which may
be active.

In general our CPU specific tuning files are a little sloppy (e.g.
defaulting to combinations of VFP versions and architecture levels
which never exist in the real world). If newer versions of gcc are
making those issues more apparent then why not take the opportunity to
fix them properly?

> > > and is preferred since gcc is getting stricter and stricter with option

> > > check semantics and can now find incompatible -march and -mcpu options

> > > better with every release. It does internal feature consistency check

> > > and if it finds out discrepency between what -mcpu would expand to as

> > > compared to -march it will flag the options to be incompatible, for

> > > naked eye it sounds wrong but gcc would translate -mcpu to a given

> > > -march internally and it might not match to what we set in these arch

> > > files.

> > >

> > > The effects are quite subtle, where this can result in configure test

> > > failing to compile due to these incompatible options and a feature

> > > option getting disabled for a recipe for no reason.

> > >

> > > e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> > > -march=armv7-a are incompatible, many features in libstdc++ ends up

> > > disabled due to configure check failures e.g. size_t size, ptrdiff_t

> > > sizes, which inturn results in compiling libstdc++ with unwanted

> > > disabled features.

> >

> > It would be interesting to see more specific details of this.

>

> These are configure tests which fail when -Werror is in use and is not

> limited to libstdc++

> it can happen in any package. Since the diagnostic about incompatible

> march mcpu pair

> is a warning in general, it does not matter, but when we have -Werror

> enabled this turns

> into error, You can simply try a small helloworld example to see the effects.

>

> >

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

> > > ---

> > >  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> > >  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> > >  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> > >  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> > >  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> > >  6 files changed, 1 insertion(+), 6 deletions(-)

> > >

> > > diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

> > > index 47a7ad2830..52d8ab1e8f 100644

> > > --- a/meta/conf/machine/include/arm/arch-armv4.inc

> > > +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> > >

> > >  TUNEVALID[arm] = "Enable ARM instruction set"

> > >  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

> > >  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

> > >  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

> > >  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

> > > diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

> > > index f9068af9de..1fe1b6b8e4 100644

> > > --- a/meta/conf/machine/include/arm/arch-armv5.inc

> > > +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> > >

> > >  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> > >  TUNECONFLICTS[armv5] = "armv4"

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

> > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

> > >

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

> > > diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

> > > index 6c838e999c..adb9be8050 100644

> > > --- a/meta/conf/machine/include/arm/arch-armv6.inc

> > > +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> > >

> > >  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> > >  TUNECONFLICTS[armv6] = "armv4 armv5"

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

> > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

> > >

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

> > > diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

> > > index a2663d8008..09d2c03a5d 100644

> > > --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> > > +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> > > @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> > >

> > >  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> > >  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

> > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

> > >

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

> > > diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > index 4d9260fecb..31e334f645 100644

> > > --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> > >

> > >  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> > >  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

> > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

> > >

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

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

> > > index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

> > >

> > >  AVAILTUNES += "iwmmxt"

> > >  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> > > --

> > > 2.20.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 Jan. 25, 2019, 3:22 a.m. | #4
On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com> wrote:
>

> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

> >

> > On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:

> > >

> > > On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

> > > >

> > > > tune files which inherit the arch definitions already define appropriate

> > > > -mcpu option, which is equivalent of right -march and -mtune combination

> > >

> > > And what about machines which inherit an arch definition instead of a

> > > cpu definition? Is that no longer supported?

> >

> > I could not find such a machine configuration in several BSP layers I looked at.

> > Do you know of machine definitions where these files are included

> > directly in machine configs ?

>

> Using a CPU specific include but then leaving the generic DEFAULTTUNE

> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

> guess quite common.


defaulttune does not play much part in appending -mcpu option to
compiler flags, A case
where this could bypass the setting mcpu is when we do not include a
tune-* for arm based machine
and thats the case I was interested to know.

again if there is such a BSP I would be interested to test it out.
>

> > if so, then we have to either use _remove or introduce a weak variable

> > to set march only if

> > mcpu is not set which

>

> I think the solution is to ensure that the CPU specific tuning options

> are always compatible with any architecture specific options which may

> be active.

>

> In general our CPU specific tuning files are a little sloppy (e.g.

> defaulting to combinations of VFP versions and architecture levels

> which never exist in the real world). If newer versions of gcc are

> making those issues more apparent then why not take the opportunity to

> fix them properly?


the mcpu option is helping with right march/mtune combination. while we can
use specific -march=arch(+-)features syntax and combine with right
-mtune to match -mcpu I think we should use
compiler defaults and not try to recreate something that -mcpu would
do it easily for us.

So either we drop the idea of setting mcpu and use basic -march value
combined with -mtune ( which btw. was default in past)
or if we want to let compiler use ISA for a particular arch
implementation ( cortexXXX ) then we should just use -mcpu and drop
using -mtune and -march.

I would include towards option 1.

>

> > > > and is preferred since gcc is getting stricter and stricter with option

> > > > check semantics and can now find incompatible -march and -mcpu options

> > > > better with every release. It does internal feature consistency check

> > > > and if it finds out discrepency between what -mcpu would expand to as

> > > > compared to -march it will flag the options to be incompatible, for

> > > > naked eye it sounds wrong but gcc would translate -mcpu to a given

> > > > -march internally and it might not match to what we set in these arch

> > > > files.

> > > >

> > > > The effects are quite subtle, where this can result in configure test

> > > > failing to compile due to these incompatible options and a feature

> > > > option getting disabled for a recipe for no reason.

> > > >

> > > > e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> > > > -march=armv7-a are incompatible, many features in libstdc++ ends up

> > > > disabled due to configure check failures e.g. size_t size, ptrdiff_t

> > > > sizes, which inturn results in compiling libstdc++ with unwanted

> > > > disabled features.

> > >

> > > It would be interesting to see more specific details of this.

> >

> > These are configure tests which fail when -Werror is in use and is not

> > limited to libstdc++

> > it can happen in any package. Since the diagnostic about incompatible

> > march mcpu pair

> > is a warning in general, it does not matter, but when we have -Werror

> > enabled this turns

> > into error, You can simply try a small helloworld example to see the effects.

> >

> > >

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

> > > > ---

> > > >  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> > > >  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> > > >  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> > > >  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> > > >  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> > > >  6 files changed, 1 insertion(+), 6 deletions(-)

> > > >

> > > > diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

> > > > index 47a7ad2830..52d8ab1e8f 100644

> > > > --- a/meta/conf/machine/include/arm/arch-armv4.inc

> > > > +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> > > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> > > >

> > > >  TUNEVALID[arm] = "Enable ARM instruction set"

> > > >  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

> > > >  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

> > > >  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

> > > >  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

> > > > diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

> > > > index f9068af9de..1fe1b6b8e4 100644

> > > > --- a/meta/conf/machine/include/arm/arch-armv5.inc

> > > > +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> > > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> > > >

> > > >  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> > > >  TUNECONFLICTS[armv5] = "armv4"

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

> > > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

> > > >

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

> > > > diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

> > > > index 6c838e999c..adb9be8050 100644

> > > > --- a/meta/conf/machine/include/arm/arch-armv6.inc

> > > > +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> > > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> > > >

> > > >  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> > > >  TUNECONFLICTS[armv6] = "armv4 armv5"

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

> > > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

> > > >

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

> > > > diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

> > > > index a2663d8008..09d2c03a5d 100644

> > > > --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> > > > +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> > > > @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> > > >

> > > >  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> > > >  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

> > > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

> > > >

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

> > > > diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > > index 4d9260fecb..31e334f645 100644

> > > > --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > > +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > > > @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> > > >

> > > >  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> > > >  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

> > > >  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

> > > >

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

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

> > > > index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

> > > >

> > > >  AVAILTUNES += "iwmmxt"

> > > >  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> > > > --

> > > > 2.20.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
Mark Hatle Jan. 25, 2019, 5:31 p.m. | #5
On 1/24/19 9:22 PM, Khem Raj wrote:
> On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>>

>> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

>>>

>>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>>>>

>>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

>>>>>

>>>>> tune files which inherit the arch definitions already define appropriate

>>>>> -mcpu option, which is equivalent of right -march and -mtune combination

>>>>

>>>> And what about machines which inherit an arch definition instead of a

>>>> cpu definition? Is that no longer supported?

>>>

>>> I could not find such a machine configuration in several BSP layers I looked at.

>>> Do you know of machine definitions where these files are included

>>> directly in machine configs ?

>>

>> Using a CPU specific include but then leaving the generic DEFAULTTUNE

>> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

>> guess quite common.

> 

> defaulttune does not play much part in appending -mcpu option to

> compiler flags, A case

> where this could bypass the setting mcpu is when we do not include a

> tune-* for arm based machine

> and thats the case I was interested to know.

> 

> again if there is such a BSP I would be interested to test it out.

>>

>>> if so, then we have to either use _remove or introduce a weak variable

>>> to set march only if

>>> mcpu is not set which

>>

>> I think the solution is to ensure that the CPU specific tuning options

>> are always compatible with any architecture specific options which may

>> be active.

>>

>> In general our CPU specific tuning files are a little sloppy (e.g.

>> defaulting to combinations of VFP versions and architecture levels

>> which never exist in the real world). If newer versions of gcc are

>> making those issues more apparent then why not take the opportunity to

>> fix them properly?

> 

> the mcpu option is helping with right march/mtune combination. while we can

> use specific -march=arch(+-)features syntax and combine with right

> -mtune to match -mcpu I think we should use

> compiler defaults and not try to recreate something that -mcpu would

> do it easily for us.

> 

> So either we drop the idea of setting mcpu and use basic -march value

> combined with -mtune ( which btw. was default in past)

> or if we want to let compiler use ISA for a particular arch

> implementation ( cortexXXX ) then we should just use -mcpu and drop

> using -mtune and -march.

> 

> I would include towards option 1.


I know this is a bit of a 'me too' response, but we have to pick one format and
stay with it.  Either option, but not both.

-IF- we know that the appropriate -mcpu options are available for all of the
potential combinations out there, then this is by far the preferred method in my
mind.  Much easier to handle and manage...

However, the more complex route came out as various 'odd-ball' (and people claim
don't exist, but they do) custom ARM cores get released without 'mandatory' math
units, or some other odd ball variation.  (I've seen this numerous times over
the last 20 years that something that doesn't exist, does... all because it's a
custom part.)

If we have an easy way to define the -mcpu= means some magic combination of
-march/-mtune within the GCC spec itself, then I'm 100% for moving to -mcpu to
rid ourselves of this mess.. and then we still have the flexibility to easily
update/add tunes and GCC configuration for the odd-balls that seem to crop up
regularly.

(I know -I- can always patch GCC for new -mcpu combinations, but I'm not
thinking about 'me', I'm thinking about the user of OE who is told 'use this
CPU, it has this set of functions' and is NOT a compiler expert who can wade
through GCC spec files and generate patches with any confidence.)

--Mark

>>

>>>>> and is preferred since gcc is getting stricter and stricter with option

>>>>> check semantics and can now find incompatible -march and -mcpu options

>>>>> better with every release. It does internal feature consistency check

>>>>> and if it finds out discrepency between what -mcpu would expand to as

>>>>> compared to -march it will flag the options to be incompatible, for

>>>>> naked eye it sounds wrong but gcc would translate -mcpu to a given

>>>>> -march internally and it might not match to what we set in these arch

>>>>> files.

>>>>>

>>>>> The effects are quite subtle, where this can result in configure test

>>>>> failing to compile due to these incompatible options and a feature

>>>>> option getting disabled for a recipe for no reason.

>>>>>

>>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

>>>>> -march=armv7-a are incompatible, many features in libstdc++ ends up

>>>>> disabled due to configure check failures e.g. size_t size, ptrdiff_t

>>>>> sizes, which inturn results in compiling libstdc++ with unwanted

>>>>> disabled features.

>>>>

>>>> It would be interesting to see more specific details of this.

>>>

>>> These are configure tests which fail when -Werror is in use and is not

>>> limited to libstdc++

>>> it can happen in any package. Since the diagnostic about incompatible

>>> march mcpu pair

>>> is a warning in general, it does not matter, but when we have -Werror

>>> enabled this turns

>>> into error, You can simply try a small helloworld example to see the effects.

>>>

>>>>

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

>>>>> ---

>>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

>>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

>>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

>>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

>>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

>>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

>>>>>

>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

>>>>> index 47a7ad2830..52d8ab1e8f 100644

>>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

>>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

>>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

>>>>>

>>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

>>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

>>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

>>>>>  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

>>>>>  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

>>>>> index f9068af9de..1fe1b6b8e4 100644

>>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

>>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

>>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

>>>>>

>>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

>>>>>  TUNECONFLICTS[armv5] = "armv4"

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

>>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

>>>>>

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

>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

>>>>> index 6c838e999c..adb9be8050 100644

>>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

>>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

>>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

>>>>>

>>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

>>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

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

>>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

>>>>>

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

>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

>>>>> index a2663d8008..09d2c03a5d 100644

>>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

>>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

>>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

>>>>>

>>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

>>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

>>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

>>>>>

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

>>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

>>>>> index 4d9260fecb..31e334f645 100644

>>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

>>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

>>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

>>>>>

>>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

>>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

>>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

>>>>>

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

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

>>>>> index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

>>>>>

>>>>>  AVAILTUNES += "iwmmxt"

>>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>>>>> --

>>>>> 2.20.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
Richard Purdie Jan. 26, 2019, 10:33 a.m. | #6
On Thu, 2019-01-24 at 22:22 -0500, Khem Raj wrote:
> On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com>

> wrote:

> > On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com>

> > wrote:

> > > On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <

> > > armccurdy@gmail.com> wrote:

> > > > On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com>

> > > > wrote:

> > > > > tune files which inherit the arch definitions already define

> > > > > appropriate

> > > > > -mcpu option, which is equivalent of right -march and -mtune

> > > > > combination

> > > > 

> > > > And what about machines which inherit an arch definition

> > > > instead of a

> > > > cpu definition? Is that no longer supported?

> > > 

> > > I could not find such a machine configuration in several BSP

> > > layers I looked at.

> > > Do you know of machine definitions where these files are included

> > > directly in machine configs ?

> > 

> > Using a CPU specific include but then leaving the generic

> > DEFAULTTUNE

> > (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

> > guess quite common.

> 

> defaulttune does not play much part in appending -mcpu option to

> compiler flags, A case

> where this could bypass the setting mcpu is when we do not include a

> tune-* for arm based machine

> and thats the case I was interested to know.

> 

> again if there is such a BSP I would be interested to test it out.

> > > if so, then we have to either use _remove or introduce a weak

> > > variable

> > > to set march only if

> > > mcpu is not set which

> > 

> > I think the solution is to ensure that the CPU specific tuning

> > options

> > are always compatible with any architecture specific options which

> > may

> > be active.

> > 

> > In general our CPU specific tuning files are a little sloppy (e.g.

> > defaulting to combinations of VFP versions and architecture levels

> > which never exist in the real world). If newer versions of gcc are

> > making those issues more apparent then why not take the opportunity

> > to

> > fix them properly?

> 

> the mcpu option is helping with right march/mtune combination. while

> we can

> use specific -march=arch(+-)features syntax and combine with right

> -mtune to match -mcpu I think we should use

> compiler defaults and not try to recreate something that -mcpu would

> do it easily for us.

> 

> So either we drop the idea of setting mcpu and use basic -march value

> combined with -mtune ( which btw. was default in past)

> or if we want to let compiler use ISA for a particular arch

> implementation ( cortexXXX ) then we should just use -mcpu and drop

> using -mtune and -march.

> 

> I would include towards option 1.


I think the friction is partly because we support "generic" tunes as
well as cpu specific ones. Having a system which allows all of these to
be switched between is hard.

I do agree we need to have a system which does one or the other and is
clearer than the current setup though.

The v2 patch isn't right as it will only work for one end result case
and won't dynamically adjust as the current code is designed to do. We
can fix that and make such a patch work, we just need to decide what
we're aiming for first and document it.

I'd also love to understand which of the tunes are actually used and
which ones we could prune out...

Cheers,

Richard



-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Jan. 26, 2019, 4:28 p.m. | #7
On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle <mark.hatle@windriver.com>
wrote:
>

> On 1/24/19 9:22 PM, Khem Raj wrote:

> > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com>

wrote:
> >>

> >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

> >>>

> >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com>

wrote:
> >>>>

> >>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

> >>>>>

> >>>>> tune files which inherit the arch definitions already define

appropriate
> >>>>> -mcpu option, which is equivalent of right -march and -mtune

combination
> >>>>

> >>>> And what about machines which inherit an arch definition instead of a

> >>>> cpu definition? Is that no longer supported?

> >>>

> >>> I could not find such a machine configuration in several BSP layers I

looked at.
> >>> Do you know of machine definitions where these files are included

> >>> directly in machine configs ?

> >>

> >> Using a CPU specific include but then leaving the generic DEFAULTTUNE

> >> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

> >> guess quite common.

> >

> > defaulttune does not play much part in appending -mcpu option to

> > compiler flags, A case

> > where this could bypass the setting mcpu is when we do not include a

> > tune-* for arm based machine

> > and thats the case I was interested to know.

> >

> > again if there is such a BSP I would be interested to test it out.

> >>

> >>> if so, then we have to either use _remove or introduce a weak variable

> >>> to set march only if

> >>> mcpu is not set which

> >>

> >> I think the solution is to ensure that the CPU specific tuning options

> >> are always compatible with any architecture specific options which may

> >> be active.

> >>

> >> In general our CPU specific tuning files are a little sloppy (e.g.

> >> defaulting to combinations of VFP versions and architecture levels

> >> which never exist in the real world). If newer versions of gcc are

> >> making those issues more apparent then why not take the opportunity to

> >> fix them properly?

> >

> > the mcpu option is helping with right march/mtune combination. while we

can
> > use specific -march=arch(+-)features syntax and combine with right

> > -mtune to match -mcpu I think we should use

> > compiler defaults and not try to recreate something that -mcpu would

> > do it easily for us.

> >

> > So either we drop the idea of setting mcpu and use basic -march value

> > combined with -mtune ( which btw. was default in past)

> > or if we want to let compiler use ISA for a particular arch

> > implementation ( cortexXXX ) then we should just use -mcpu and drop

> > using -mtune and -march.

> >

> > I would include towards option 1.

>

> I know this is a bit of a 'me too' response, but we have to pick one

format and
> stay with it.  Either option, but not both.


I concur.


>

> -IF- we know that the appropriate -mcpu options are available for all of

the
> potential combinations out there, then this is by far the preferred

method in my
> mind.  Much easier to handle and manage...


-mcpu options are available for known CPU implementations. But there always
will
be weird ones, given how people can pick and choose subsystems for SOC on
this
architecture, and its highly probable that they wont be in gcc. so real
question we need to answer for is, should we design for those cases and how
often does this often.


>

> However, the more complex route came out as various 'odd-ball' (and

people claim
> don't exist, but they do) custom ARM cores get released without

'mandatory' math
> units, or some other odd ball variation.  (I've seen this numerous times

over
> the last 20 years that something that doesn't exist, does... all because

it's a
> custom part.)


Yes, I am dealing with one such design even today


>

> If we have an easy way to define the -mcpu= means some magic combination

of
> -march/-mtune within the GCC spec itself, then I'm 100% for moving to

-mcpu to
> rid ourselves of this mess.. and then we still have the flexibility to

easily
> update/add tunes and GCC configuration for the odd-balls that seem to

crop up
> regularly.


So yes we can do nearly same but not exactly same. We have to start adding
or deleting
features via -march and -mtune would be same value, but there are cases
where gcc defines
internal properties based on mcpu, that is not representable in those
suffixes we will add. so
we will come very close but not exact and I think compiler is right in this
case because we
are not exactly telling it about a CPU implementation, but we are telling
the cpu has these properties, so it really may not be one of standard cpu
implementation.


>

> (I know -I- can always patch GCC for new -mcpu combinations, but I'm not

> thinking about 'me', I'm thinking about the user of OE who is told 'use

this
> CPU, it has this set of functions' and is NOT a compiler expert who can

wade
> through GCC spec files and generate patches with any confidence.)

>


I would think we can solve this for these niche cases, via using
-march/-mtune and drop
-mcpu, we can append adding/deleting a given feature e.g. neon or vfp or
vfpv3 etc.
but this would mean we have to rename our package feed names as well to
match this
new representation, which currently is mapped to mcpu values. This is quite
a departure
from package feeds point of view. but its more aligned with how we have
defined arch and tunes.
so pick the battles.


> --Mark

>

> >>

> >>>>> and is preferred since gcc is getting stricter and stricter with

option
> >>>>> check semantics and can now find incompatible -march and -mcpu

options
> >>>>> better with every release. It does internal feature consistency

check
> >>>>> and if it finds out discrepency between what -mcpu would expand to

as
> >>>>> compared to -march it will flag the options to be incompatible, for

> >>>>> naked eye it sounds wrong but gcc would translate -mcpu to a given

> >>>>> -march internally and it might not match to what we set in these

arch
> >>>>> files.

> >>>>>

> >>>>> The effects are quite subtle, where this can result in configure

test
> >>>>> failing to compile due to these incompatible options and a feature

> >>>>> option getting disabled for a recipe for no reason.

> >>>>>

> >>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> >>>>> -march=armv7-a are incompatible, many features in libstdc++ ends up

> >>>>> disabled due to configure check failures e.g. size_t size, ptrdiff_t

> >>>>> sizes, which inturn results in compiling libstdc++ with unwanted

> >>>>> disabled features.

> >>>>

> >>>> It would be interesting to see more specific details of this.

> >>>

> >>> These are configure tests which fail when -Werror is in use and is not

> >>> limited to libstdc++

> >>> it can happen in any package. Since the diagnostic about incompatible

> >>> march mcpu pair

> >>> is a warning in general, it does not matter, but when we have -Werror

> >>> enabled this turns

> >>> into error, You can simply try a small helloworld example to see the

effects.
> >>>

> >>>>

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

> >>>>> ---

> >>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> >>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> >>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> >>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> >>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> >>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

> >>>>>

> >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc

b/meta/conf/machine/include/arm/arch-armv4.inc
> >>>>> index 47a7ad2830..52d8ab1e8f 100644

> >>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

> >>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> >>>>>

> >>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

> >>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

> >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', '

-march=armv4t', '', d)}"
> >>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then

disable it when we have also armv5 or thumb
> >>>>>  # maybe we should extend bb.utils.contains to support check for

any checkvalues in value, now it does
> >>>>>  # checkvalues.issubset(val) which cannot be used for negative test

of foo neither bar in value
> >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc

b/meta/conf/machine/include/arm/arch-armv5.inc
> >>>>> index f9068af9de..1fe1b6b8e4 100644

> >>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

> >>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> >>>>>

> >>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> >>>>>  TUNECONFLICTS[armv5] = "armv4"

> >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', '

-march=armv5t${ARMPKGSFX_DSP}', '', d)}"
> >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

'armv5', 'armv5:', '' ,d)}"
> >>>>>

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

> >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc

b/meta/conf/machine/include/arm/arch-armv6.inc
> >>>>> index 6c838e999c..adb9be8050 100644

> >>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

> >>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> >>>>>

> >>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> >>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

> >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', '

-march=armv6', '', d)}"
> >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

'armv6', 'armv6:', '' ,d)}"
> >>>>>

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

> >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc

b/meta/conf/machine/include/arm/arch-armv7a.inc
> >>>>> index a2663d8008..09d2c03a5d 100644

> >>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> >>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> >>>>>

> >>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> >>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

> >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', '

-march=armv7-a', '', d)}"
> >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

'armv7a', 'armv7a:', '' ,d)}"
> >>>>>

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

> >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc

b/meta/conf/machine/include/arm/arch-armv7ve.inc
> >>>>> index 4d9260fecb..31e334f645 100644

> >>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> >>>>>

> >>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> >>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

> >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', '

-march=armv7ve', '', d)}"
> >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

'armv7ve', 'armv7ve:', '' ,d)}"
> >>>>>

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

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

b/meta/conf/machine/include/tune-iwmmxt.inc
> >>>>> index f27423cb2e..6e577697cc 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', '

-mcpu=iwmmxt', '', d)}"
> >>>>>

> >>>>>  AVAILTUNES += "iwmmxt"

> >>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> >>>>> --

> >>>>> 2.20.1

> >>>>>

> >>>>> --

> >>>>> _______________________________________________

> >>>>> Openembedded-core mailing list

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

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

>
<div><br>
On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle &lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 1/24/19 9:22 PM, Khem Raj wrote:<br>
&gt; &gt; On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Wed, Jan 23, 2019 at 2:50 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; On Wed, Jan 23, 2019 at 12:05 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; tune files which inherit the arch definitions already define appropriate<br>
&gt; &gt;&gt;&gt;&gt;&gt; -mcpu option, which is equivalent of right -march and -mtune combination<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; And what about machines which inherit an arch definition instead of a<br>
&gt; &gt;&gt;&gt;&gt; cpu definition? Is that no longer supported?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I could not find such a machine configuration in several BSP layers I looked at.<br>
&gt; &gt;&gt;&gt; Do you know of machine definitions where these files are included<br>
&gt; &gt;&gt;&gt; directly in machine configs ?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Using a CPU specific include but then leaving the generic DEFAULTTUNE<br>
&gt; &gt;&gt; (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I<br>
&gt; &gt;&gt; guess quite common.<br>
&gt; &gt;<br>
&gt; &gt; defaulttune does not play much part in appending -mcpu option to<br>
&gt; &gt; compiler flags, A case<br>
&gt; &gt; where this could bypass the setting mcpu is when we do not include a<br>
&gt; &gt; tune-* for arm based machine<br>
&gt; &gt; and thats the case I was interested to know.<br>
&gt; &gt;<br>
&gt; &gt; again if there is such a BSP I would be interested to test it out.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; if so, then we have to either use _remove or introduce a weak variable<br>
&gt; &gt;&gt;&gt; to set march only if<br>
&gt; &gt;&gt;&gt; mcpu is not set which<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I think the solution is to ensure that the CPU specific tuning options<br>
&gt; &gt;&gt; are always compatible with any architecture specific options which may<br>
&gt; &gt;&gt; be active.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; In general our CPU specific tuning files are a little sloppy (e.g.<br>
&gt; &gt;&gt; defaulting to combinations of VFP versions and architecture levels<br>
&gt; &gt;&gt; which never exist in the real world). If newer versions of gcc are<br>
&gt; &gt;&gt; making those issues more apparent then why not take the opportunity to<br>
&gt; &gt;&gt; fix them properly?<br>
&gt; &gt;<br>
&gt; &gt; the mcpu option is helping with right march/mtune combination. while we can<br>
&gt; &gt; use specific -march=arch(+-)features syntax and combine with right<br>
&gt; &gt; -mtune to match -mcpu I think we should use<br>
&gt; &gt; compiler defaults and not try to recreate something that -mcpu would<br>
&gt; &gt; do it easily for us.<br>
&gt; &gt;<br>
&gt; &gt; So either we drop the idea of setting mcpu and use basic -march value<br>
&gt; &gt; combined with -mtune ( which btw. was default in past)<br>
&gt; &gt; or if we want to let compiler use ISA for a particular arch<br>
&gt; &gt; implementation ( cortexXXX ) then we should just use -mcpu and drop<br>
&gt; &gt; using -mtune and -march.<br>
&gt; &gt;<br>
&gt; &gt; I would include towards option 1.<br>
&gt;<br>
&gt; I know this is a bit of a &#39;me too&#39; response, but we have to pick one format and<br>
&gt; stay with it.  Either option, but not both.<br>
<br></div><div>
I concur.</div><div><br>
<br>
&gt;<br>
&gt; -IF- we know that the appropriate -mcpu options are available for all of the<br>
&gt; potential combinations out there, then this is by far the preferred method in my<br>
&gt; mind.  Much easier to handle and manage...<br>
<br></div><div>
-mcpu options are available for known CPU implementations. But there always will<br>
be weird ones, given how people can pick and choose subsystems for SOC on this<br>
architecture, and its highly probable that they wont be in gcc. so real question we need to answer for is, should we design for those cases and how often does this often.</div><div><br>
<br>
&gt;<br>
&gt; However, the more complex route came out as various &#39;odd-ball&#39; (and people claim<br>
&gt; don&#39;t exist, but they do) custom ARM cores get released without &#39;mandatory&#39; math<br>
&gt; units, or some other odd ball variation.  (I&#39;ve seen this numerous times over<br>
&gt; the last 20 years that something that doesn&#39;t exist, does... all because it&#39;s a<br>
&gt; custom part.)<br>
<br></div><div><div dir="auto">
Yes, I am dealing with one such design even today</div></div><div><br>
<br>
&gt;<br>
&gt; If we have an easy way to define the -mcpu= means some magic combination of<br>
&gt; -march/-mtune within the GCC spec itself, then I&#39;m 100% for moving to -mcpu to<br>
&gt; rid ourselves of this mess.. and then we still have the flexibility to easily<br>
&gt; update/add tunes and GCC configuration for the odd-balls that seem to crop up<br>
&gt; regularly.<br>
<br></div><div>
So yes we can do nearly same but not exactly same. We have to start adding or deleting<br>
features via -march and -mtune would be same value, but there are cases where gcc defines<br>
internal properties based on mcpu, that is not representable in those suffixes we will add. so<br>
we will come very close but not exact and I think compiler is right in this case because we<br>
are not exactly telling it about a CPU implementation, but we are telling the cpu has these properties, so it really may not be one of standard cpu implementation.</div><div><br>
<br>
&gt;<br>
&gt; (I know -I- can always patch GCC for new -mcpu combinations, but I&#39;m not<br>
&gt; thinking about &#39;me&#39;, I&#39;m thinking about the user of OE who is told &#39;use this<br>
&gt; CPU, it has this set of functions&#39; and is NOT a compiler expert who can wade<br>
&gt; through GCC spec files and generate patches with any confidence.)<br>
&gt;<br>
<br></div><div>
I would think we can solve this for these niche cases, via using -march/-mtune and drop<br>
-mcpu, we can append adding/deleting a given feature e.g. neon or vfp or vfpv3 etc.<br>
but this would mean we have to rename our package feed names as well to match this<br>
new representation, which currently is mapped to mcpu values. This is quite a departure<br>
from package feeds point of view. but its more aligned with how we have defined arch and tunes.<br>
so pick the battles.</div><div><br>
<br>
&gt; --Mark<br>
&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; and is preferred since gcc is getting stricter and stricter with option<br>
&gt; &gt;&gt;&gt;&gt;&gt; check semantics and can now find incompatible -march and -mcpu options<br>
&gt; &gt;&gt;&gt;&gt;&gt; better with every release. It does internal feature consistency check<br>
&gt; &gt;&gt;&gt;&gt;&gt; and if it finds out discrepency between what -mcpu would expand to as<br>
&gt; &gt;&gt;&gt;&gt;&gt; compared to -march it will flag the options to be incompatible, for<br>
&gt; &gt;&gt;&gt;&gt;&gt; naked eye it sounds wrong but gcc would translate -mcpu to a given<br>
&gt; &gt;&gt;&gt;&gt;&gt; -march internally and it might not match to what we set in these arch<br>
&gt; &gt;&gt;&gt;&gt;&gt; files.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; The effects are quite subtle, where this can result in configure test<br>
&gt; &gt;&gt;&gt;&gt;&gt; failing to compile due to these incompatible options and a feature<br>
&gt; &gt;&gt;&gt;&gt;&gt; option getting disabled for a recipe for no reason.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and<br>
&gt; &gt;&gt;&gt;&gt;&gt; -march=armv7-a are incompatible, many features in libstdc++ ends up<br>
&gt; &gt;&gt;&gt;&gt;&gt; disabled due to configure check failures e.g. size_t size, ptrdiff_t<br>
&gt; &gt;&gt;&gt;&gt;&gt; sizes, which inturn results in compiling libstdc++ with unwanted<br>
&gt; &gt;&gt;&gt;&gt;&gt; disabled features.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; It would be interesting to see more specific details of this.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; These are configure tests which fail when -Werror is in use and is not<br>
&gt; &gt;&gt;&gt; limited to libstdc++<br>
&gt; &gt;&gt;&gt; it can happen in any package. Since the diagnostic about incompatible<br>
&gt; &gt;&gt;&gt; march mcpu pair<br>
&gt; &gt;&gt;&gt; is a warning in general, it does not matter, but when we have -Werror<br>
&gt; &gt;&gt;&gt; enabled this turns<br>
&gt; &gt;&gt;&gt; into error, You can simply try a small helloworld example to see the effects.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; Signed-off-by: Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; ---<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/tune-iwmmxt.inc      | 2 +-<br>
&gt; &gt;&gt;&gt;&gt;&gt;  6 files changed, 1 insertion(+), 6 deletions(-)<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 47a7ad2830..52d8ab1e8f 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[arm] = &quot;Enable ARM instruction set&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv4] = &quot;Enable instructions for ARMv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv4&#39;, &#39; -march=armv4t&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index f9068af9de..1fe1b6b8e4 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv5] = &quot;Enable instructions for ARMv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv5] = &quot;armv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39; -march=armv5t${ARMPKGSFX_DSP}&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39;armv5:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 6c838e999c..adb9be8050 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv6hf&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv6] = &quot;Enable instructions for ARMv6&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv6] = &quot;armv4 armv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39; -march=armv6&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39;armv6:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index a2663d8008..09d2c03a5d 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= &quot;thumb&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7a] = &quot;Enable instructions for ARMv7-a&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7a] = &quot;armv4 armv5 armv6 armv7&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39; -march=armv7-a&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39;armv7a:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 4d9260fecb..31e334f645 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv7vethf&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7ve] = &quot;Enable instructions for ARMv7ve&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7ve] = &quot;armv4 armv5 armv6 armv7 armv7a&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39; -march=armv7ve&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39;armv7ve:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index f27423cb2e..6e577697cc 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -6,7 +6,7 @@ DEFAULTTUNE ?= &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[iwmmxt] = &quot;Enable Intel PXA27x specific processor optimizations&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -march=iwmmxt -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; +TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  AVAILTUNES += &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  ARMPKGARCH_tune-iwmmxt = &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt; 2.20.1<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt; &gt;&gt;&gt;&gt;&gt; Openembedded-core mailing list<br>
&gt; &gt;&gt;&gt;&gt;&gt; <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
&gt; &gt;&gt;&gt;&gt;&gt; <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
&gt;<br>
</div>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Martin Jansa Jan. 26, 2019, 5:39 p.m. | #8
Which -mcpu/-march combination is causing issue in gcc9?

I know we had this issue with armv7a tunes before, that's why I've added
separate armv7ve before the switch from -mtune to -mcpu.

I still believe -mcpu (with or without -march) is better option.

Using -mtune without indicating which -mtune was actually used in the
package arch is bad (especially if you have multiple MACHINEs with
different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending
in armv7a package arch, unpacking all packages from sstate every time you
switch MACHINE and the package manager on target never knowing which -mtune
was used to build given package upgrade from feed).

Switching from -mcpu to -mtune while keeping the current cpu-specific
package architectures is better, but then the use case, that I build
everything e.g. with cortexa8 in -mtune and install this cortexa8 package
feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime,
but why not use generic armv7a DEFAULTTUNE to make it clear (to package
manager as well as end user) that I'm not really optimizing for given CPU).

From the naive openssl benchmarks I did few years back, there was very
small difference between mtune/mcpu/just-march, but still for projects
where I have separate package feeds for each device (e.g. LG TVs) I prefer
to use -mcpu (because I really know that such packages won't ever be used
on device with different CPU) and e.g. in LuneOS we're more concerned about
package feed size and build time, so we select more generic DEFAULTTUNE
which is shared across many MACHINEs and that doesn't have any -mcpu (nor
-mtune) options in it, so should be fine as well.

We can easily extend the tune-test script I've used back then when
switching to -mcpu to not only use bitbake -e, but also call gcc-cross to
check for possible warnings from incompatible march/mcpu combinations and
fix those. The old version is here:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
it was used in mcpu switch here:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test

http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3

From the gcc git log I don't see many changes in:
https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c
nor
https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in
so I'm really interested which combination issues the warning now.

Regards,

On Sat, Jan 26, 2019 at 5:29 PM Khem Raj <raj.khem@gmail.com> wrote:

>

> On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle <mark.hatle@windriver.com>

> wrote:

> >

> > On 1/24/19 9:22 PM, Khem Raj wrote:

> > > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com>

> wrote:

> > >>

> > >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

> > >>>

> > >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com>

> wrote:

> > >>>>

> > >>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com>

> wrote:

> > >>>>>

> > >>>>> tune files which inherit the arch definitions already define

> appropriate

> > >>>>> -mcpu option, which is equivalent of right -march and -mtune

> combination

> > >>>>

> > >>>> And what about machines which inherit an arch definition instead of

> a

> > >>>> cpu definition? Is that no longer supported?

> > >>>

> > >>> I could not find such a machine configuration in several BSP layers

> I looked at.

> > >>> Do you know of machine definitions where these files are included

> > >>> directly in machine configs ?

> > >>

> > >> Using a CPU specific include but then leaving the generic DEFAULTTUNE

> > >> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

> > >> guess quite common.

> > >

> > > defaulttune does not play much part in appending -mcpu option to

> > > compiler flags, A case

> > > where this could bypass the setting mcpu is when we do not include a

> > > tune-* for arm based machine

> > > and thats the case I was interested to know.

> > >

> > > again if there is such a BSP I would be interested to test it out.

> > >>

> > >>> if so, then we have to either use _remove or introduce a weak

> variable

> > >>> to set march only if

> > >>> mcpu is not set which

> > >>

> > >> I think the solution is to ensure that the CPU specific tuning options

> > >> are always compatible with any architecture specific options which may

> > >> be active.

> > >>

> > >> In general our CPU specific tuning files are a little sloppy (e.g.

> > >> defaulting to combinations of VFP versions and architecture levels

> > >> which never exist in the real world). If newer versions of gcc are

> > >> making those issues more apparent then why not take the opportunity to

> > >> fix them properly?

> > >

> > > the mcpu option is helping with right march/mtune combination. while

> we can

> > > use specific -march=arch(+-)features syntax and combine with right

> > > -mtune to match -mcpu I think we should use

> > > compiler defaults and not try to recreate something that -mcpu would

> > > do it easily for us.

> > >

> > > So either we drop the idea of setting mcpu and use basic -march value

> > > combined with -mtune ( which btw. was default in past)

> > > or if we want to let compiler use ISA for a particular arch

> > > implementation ( cortexXXX ) then we should just use -mcpu and drop

> > > using -mtune and -march.

> > >

> > > I would include towards option 1.

> >

> > I know this is a bit of a 'me too' response, but we have to pick one

> format and

> > stay with it.  Either option, but not both.

>

> I concur.

>

>

> >

> > -IF- we know that the appropriate -mcpu options are available for all of

> the

> > potential combinations out there, then this is by far the preferred

> method in my

> > mind.  Much easier to handle and manage...

>

> -mcpu options are available for known CPU implementations. But there

> always will

> be weird ones, given how people can pick and choose subsystems for SOC on

> this

> architecture, and its highly probable that they wont be in gcc. so real

> question we need to answer for is, should we design for those cases and how

> often does this often.

>

>

> >

> > However, the more complex route came out as various 'odd-ball' (and

> people claim

> > don't exist, but they do) custom ARM cores get released without

> 'mandatory' math

> > units, or some other odd ball variation.  (I've seen this numerous times

> over

> > the last 20 years that something that doesn't exist, does... all because

> it's a

> > custom part.)

>

> Yes, I am dealing with one such design even today

>

>

> >

> > If we have an easy way to define the -mcpu= means some magic combination

> of

> > -march/-mtune within the GCC spec itself, then I'm 100% for moving to

> -mcpu to

> > rid ourselves of this mess.. and then we still have the flexibility to

> easily

> > update/add tunes and GCC configuration for the odd-balls that seem to

> crop up

> > regularly.

>

> So yes we can do nearly same but not exactly same. We have to start adding

> or deleting

> features via -march and -mtune would be same value, but there are cases

> where gcc defines

> internal properties based on mcpu, that is not representable in those

> suffixes we will add. so

> we will come very close but not exact and I think compiler is right in

> this case because we

> are not exactly telling it about a CPU implementation, but we are telling

> the cpu has these properties, so it really may not be one of standard cpu

> implementation.

>

>

> >

> > (I know -I- can always patch GCC for new -mcpu combinations, but I'm not

> > thinking about 'me', I'm thinking about the user of OE who is told 'use

> this

> > CPU, it has this set of functions' and is NOT a compiler expert who can

> wade

> > through GCC spec files and generate patches with any confidence.)

> >

>

> I would think we can solve this for these niche cases, via using

> -march/-mtune and drop

> -mcpu, we can append adding/deleting a given feature e.g. neon or vfp or

> vfpv3 etc.

> but this would mean we have to rename our package feed names as well to

> match this

> new representation, which currently is mapped to mcpu values. This is

> quite a departure

> from package feeds point of view. but its more aligned with how we have

> defined arch and tunes.

> so pick the battles.

>

>

> > --Mark

> >

> > >>

> > >>>>> and is preferred since gcc is getting stricter and stricter with

> option

> > >>>>> check semantics and can now find incompatible -march and -mcpu

> options

> > >>>>> better with every release. It does internal feature consistency

> check

> > >>>>> and if it finds out discrepency between what -mcpu would expand to

> as

> > >>>>> compared to -march it will flag the options to be incompatible, for

> > >>>>> naked eye it sounds wrong but gcc would translate -mcpu to a given

> > >>>>> -march internally and it might not match to what we set in these

> arch

> > >>>>> files.

> > >>>>>

> > >>>>> The effects are quite subtle, where this can result in configure

> test

> > >>>>> failing to compile due to these incompatible options and a feature

> > >>>>> option getting disabled for a recipe for no reason.

> > >>>>>

> > >>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> > >>>>> -march=armv7-a are incompatible, many features in libstdc++ ends up

> > >>>>> disabled due to configure check failures e.g. size_t size,

> ptrdiff_t

> > >>>>> sizes, which inturn results in compiling libstdc++ with unwanted

> > >>>>> disabled features.

> > >>>>

> > >>>> It would be interesting to see more specific details of this.

> > >>>

> > >>> These are configure tests which fail when -Werror is in use and is

> not

> > >>> limited to libstdc++

> > >>> it can happen in any package. Since the diagnostic about incompatible

> > >>> march mcpu pair

> > >>> is a warning in general, it does not matter, but when we have -Werror

> > >>> enabled this turns

> > >>> into error, You can simply try a small helloworld example to see the

> effects.

> > >>>

> > >>>>

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

> > >>>>> ---

> > >>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> > >>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> > >>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> > >>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> > >>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> > >>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

> > >>>>>

> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc

> b/meta/conf/machine/include/arm/arch-armv4.inc

> > >>>>> index 47a7ad2830..52d8ab1e8f 100644

> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> > >>>>>

> > >>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

> > >>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', '

> -march=armv4t', '', d)}"

> > >>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then

> disable it when we have also armv5 or thumb

> > >>>>>  # maybe we should extend bb.utils.contains to support check for

> any checkvalues in value, now it does

> > >>>>>  # checkvalues.issubset(val) which cannot be used for negative

> test of foo neither bar in value

> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc

> b/meta/conf/machine/include/arm/arch-armv5.inc

> > >>>>> index f9068af9de..1fe1b6b8e4 100644

> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> > >>>>>

> > >>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> > >>>>>  TUNECONFLICTS[armv5] = "armv4"

> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', '

> -march=armv5t${ARMPKGSFX_DSP}', '', d)}"

> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv5', 'armv5:', '' ,d)}"

> > >>>>>

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

> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc

> b/meta/conf/machine/include/arm/arch-armv6.inc

> > >>>>> index 6c838e999c..adb9be8050 100644

> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> > >>>>>

> > >>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> > >>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', '

> -march=armv6', '', d)}"

> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv6', 'armv6:', '' ,d)}"

> > >>>>>

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

> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc

> b/meta/conf/machine/include/arm/arch-armv7a.inc

> > >>>>> index a2663d8008..09d2c03a5d 100644

> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> > >>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> > >>>>>

> > >>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> > >>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', '

> -march=armv7-a', '', d)}"

> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7a', 'armv7a:', '' ,d)}"

> > >>>>>

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

> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc

> b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > >>>>> index 4d9260fecb..31e334f645 100644

> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> > >>>>>

> > >>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> > >>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve',

> ' -march=armv7ve', '', d)}"

> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7ve', 'armv7ve:', '' ,d)}"

> > >>>>>

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

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

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

> > >>>>> index f27423cb2e..6e577697cc 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', '

> -mcpu=iwmmxt', '', d)}"

> > >>>>>

> > >>>>>  AVAILTUNES += "iwmmxt"

> > >>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> > >>>>> --

> > >>>>> 2.20.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

>
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Which -mcpu/-march combination is causing issue in gcc9?<div><br></div><div>I know we had this issue with armv7a tunes before, that&#39;s why I&#39;ve added separate armv7ve before the switch from -mtune to -mcpu.</div><div><br></div><div>I still believe -mcpu (with or without -march) is better option.</div><div><br></div><div>Using -mtune without indicating which -mtune was actually used in the package arch is bad (especially if you have multiple MACHINEs with different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending in armv7a package arch, unpacking all packages from sstate every time you switch MACHINE and the package manager on target never knowing which -mtune was used to build given package upgrade from feed).</div><div><br></div><div>Switching from -mcpu to -mtune while keeping the current cpu-specific package architectures is better, but then the use case, that I build everything e.g. with cortexa8 in -mtune and install this cortexa8 package feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime, but why not use generic armv7a DEFAULTTUNE to make it clear (to package manager as well as end user) that I&#39;m not really optimizing for given CPU).</div><div><br></div><div>From the naive openssl benchmarks I did few years back, there was very small difference between mtune/mcpu/just-march, but still for projects where I have separate package feeds for each device (e.g. LG TVs) I prefer to use -mcpu (because I really know that such packages won&#39;t ever be used on device with different CPU) and e.g. in LuneOS we&#39;re more concerned about package feed size and build time, so we select more generic DEFAULTTUNE which is shared across many MACHINEs and that doesn&#39;t have any -mcpu (nor -mtune) options in it, so should be fine as well.</div><div><br></div><div>We can easily extend the tune-test script I&#39;ve used back then when switching to -mcpu to not only use bitbake -e, but also call gcc-cross to check for possible warnings from incompatible march/mcpu combinations and fix those. The old version is here:</div><div><a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test</a><br></div><div>it was used in mcpu switch here:</div><div><a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test</a>  <br></div><div><a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3</a></div><div><br></div><div>From the gcc git log I don&#39;t see many changes in:</div><div><a href="https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c">https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c</a><br></div><div>nor</div><div><a href="https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in">https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in</a><br></div><div>so I&#39;m really interested which combination issues the warning now.</div><div><br></div><div>Regards,</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 26, 2019 at 5:29 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle &lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 1/24/19 9:22 PM, Khem Raj wrote:<br>
&gt; &gt; On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Wed, Jan 23, 2019 at 2:50 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; On Wed, Jan 23, 2019 at 12:05 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; tune files which inherit the arch definitions already define appropriate<br>
&gt; &gt;&gt;&gt;&gt;&gt; -mcpu option, which is equivalent of right -march and -mtune combination<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; And what about machines which inherit an arch definition instead of a<br>
&gt; &gt;&gt;&gt;&gt; cpu definition? Is that no longer supported?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I could not find such a machine configuration in several BSP layers I looked at.<br>
&gt; &gt;&gt;&gt; Do you know of machine definitions where these files are included<br>
&gt; &gt;&gt;&gt; directly in machine configs ?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Using a CPU specific include but then leaving the generic DEFAULTTUNE<br>
&gt; &gt;&gt; (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I<br>
&gt; &gt;&gt; guess quite common.<br>
&gt; &gt;<br>
&gt; &gt; defaulttune does not play much part in appending -mcpu option to<br>
&gt; &gt; compiler flags, A case<br>
&gt; &gt; where this could bypass the setting mcpu is when we do not include a<br>
&gt; &gt; tune-* for arm based machine<br>
&gt; &gt; and thats the case I was interested to know.<br>
&gt; &gt;<br>
&gt; &gt; again if there is such a BSP I would be interested to test it out.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; if so, then we have to either use _remove or introduce a weak variable<br>
&gt; &gt;&gt;&gt; to set march only if<br>
&gt; &gt;&gt;&gt; mcpu is not set which<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I think the solution is to ensure that the CPU specific tuning options<br>
&gt; &gt;&gt; are always compatible with any architecture specific options which may<br>
&gt; &gt;&gt; be active.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; In general our CPU specific tuning files are a little sloppy (e.g.<br>
&gt; &gt;&gt; defaulting to combinations of VFP versions and architecture levels<br>
&gt; &gt;&gt; which never exist in the real world). If newer versions of gcc are<br>
&gt; &gt;&gt; making those issues more apparent then why not take the opportunity to<br>
&gt; &gt;&gt; fix them properly?<br>
&gt; &gt;<br>
&gt; &gt; the mcpu option is helping with right march/mtune combination. while we can<br>
&gt; &gt; use specific -march=arch(+-)features syntax and combine with right<br>
&gt; &gt; -mtune to match -mcpu I think we should use<br>
&gt; &gt; compiler defaults and not try to recreate something that -mcpu would<br>
&gt; &gt; do it easily for us.<br>
&gt; &gt;<br>
&gt; &gt; So either we drop the idea of setting mcpu and use basic -march value<br>
&gt; &gt; combined with -mtune ( which btw. was default in past)<br>
&gt; &gt; or if we want to let compiler use ISA for a particular arch<br>
&gt; &gt; implementation ( cortexXXX ) then we should just use -mcpu and drop<br>
&gt; &gt; using -mtune and -march.<br>
&gt; &gt;<br>
&gt; &gt; I would include towards option 1.<br>
&gt;<br>
&gt; I know this is a bit of a &#39;me too&#39; response, but we have to pick one format and<br>
&gt; stay with it.  Either option, but not both.<br>
<br></div><div>
I concur.</div><div><br>
<br>
&gt;<br>
&gt; -IF- we know that the appropriate -mcpu options are available for all of the<br>
&gt; potential combinations out there, then this is by far the preferred method in my<br>
&gt; mind.  Much easier to handle and manage...<br>
<br></div><div>
-mcpu options are available for known CPU implementations. But there always will<br>
be weird ones, given how people can pick and choose subsystems for SOC on this<br>
architecture, and its highly probable that they wont be in gcc. so real question we need to answer for is, should we design for those cases and how often does this often.</div><div><br>
<br>
&gt;<br>
&gt; However, the more complex route came out as various &#39;odd-ball&#39; (and people claim<br>
&gt; don&#39;t exist, but they do) custom ARM cores get released without &#39;mandatory&#39; math<br>
&gt; units, or some other odd ball variation.  (I&#39;ve seen this numerous times over<br>
&gt; the last 20 years that something that doesn&#39;t exist, does... all because it&#39;s a<br>
&gt; custom part.)<br>
<br></div><div><div dir="auto">
Yes, I am dealing with one such design even today</div></div><div><br>
<br>
&gt;<br>
&gt; If we have an easy way to define the -mcpu= means some magic combination of<br>
&gt; -march/-mtune within the GCC spec itself, then I&#39;m 100% for moving to -mcpu to<br>
&gt; rid ourselves of this mess.. and then we still have the flexibility to easily<br>
&gt; update/add tunes and GCC configuration for the odd-balls that seem to crop up<br>
&gt; regularly.<br>
<br></div><div>
So yes we can do nearly same but not exactly same. We have to start adding or deleting<br>
features via -march and -mtune would be same value, but there are cases where gcc defines<br>
internal properties based on mcpu, that is not representable in those suffixes we will add. so<br>
we will come very close but not exact and I think compiler is right in this case because we<br>
are not exactly telling it about a CPU implementation, but we are telling the cpu has these properties, so it really may not be one of standard cpu implementation.</div><div><br>
<br>
&gt;<br>
&gt; (I know -I- can always patch GCC for new -mcpu combinations, but I&#39;m not<br>
&gt; thinking about &#39;me&#39;, I&#39;m thinking about the user of OE who is told &#39;use this<br>
&gt; CPU, it has this set of functions&#39; and is NOT a compiler expert who can wade<br>
&gt; through GCC spec files and generate patches with any confidence.)<br>
&gt;<br>
<br></div><div>
I would think we can solve this for these niche cases, via using -march/-mtune and drop<br>
-mcpu, we can append adding/deleting a given feature e.g. neon or vfp or vfpv3 etc.<br>
but this would mean we have to rename our package feed names as well to match this<br>
new representation, which currently is mapped to mcpu values. This is quite a departure<br>
from package feeds point of view. but its more aligned with how we have defined arch and tunes.<br>
so pick the battles.</div><div><br>
<br>
&gt; --Mark<br>
&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; and is preferred since gcc is getting stricter and stricter with option<br>
&gt; &gt;&gt;&gt;&gt;&gt; check semantics and can now find incompatible -march and -mcpu options<br>
&gt; &gt;&gt;&gt;&gt;&gt; better with every release. It does internal feature consistency check<br>
&gt; &gt;&gt;&gt;&gt;&gt; and if it finds out discrepency between what -mcpu would expand to as<br>
&gt; &gt;&gt;&gt;&gt;&gt; compared to -march it will flag the options to be incompatible, for<br>
&gt; &gt;&gt;&gt;&gt;&gt; naked eye it sounds wrong but gcc would translate -mcpu to a given<br>
&gt; &gt;&gt;&gt;&gt;&gt; -march internally and it might not match to what we set in these arch<br>
&gt; &gt;&gt;&gt;&gt;&gt; files.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; The effects are quite subtle, where this can result in configure test<br>
&gt; &gt;&gt;&gt;&gt;&gt; failing to compile due to these incompatible options and a feature<br>
&gt; &gt;&gt;&gt;&gt;&gt; option getting disabled for a recipe for no reason.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and<br>
&gt; &gt;&gt;&gt;&gt;&gt; -march=armv7-a are incompatible, many features in libstdc++ ends up<br>
&gt; &gt;&gt;&gt;&gt;&gt; disabled due to configure check failures e.g. size_t size, ptrdiff_t<br>
&gt; &gt;&gt;&gt;&gt;&gt; sizes, which inturn results in compiling libstdc++ with unwanted<br>
&gt; &gt;&gt;&gt;&gt;&gt; disabled features.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; It would be interesting to see more specific details of this.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; These are configure tests which fail when -Werror is in use and is not<br>
&gt; &gt;&gt;&gt; limited to libstdc++<br>
&gt; &gt;&gt;&gt; it can happen in any package. Since the diagnostic about incompatible<br>
&gt; &gt;&gt;&gt; march mcpu pair<br>
&gt; &gt;&gt;&gt; is a warning in general, it does not matter, but when we have -Werror<br>
&gt; &gt;&gt;&gt; enabled this turns<br>
&gt; &gt;&gt;&gt; into error, You can simply try a small helloworld example to see the effects.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; Signed-off-by: Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; ---<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -<br>
&gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/tune-iwmmxt.inc      | 2 +-<br>
&gt; &gt;&gt;&gt;&gt;&gt;  6 files changed, 1 insertion(+), 6 deletions(-)<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 47a7ad2830..52d8ab1e8f 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[arm] = &quot;Enable ARM instruction set&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv4] = &quot;Enable instructions for ARMv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv4&#39;, &#39; -march=armv4t&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does<br>
&gt; &gt;&gt;&gt;&gt;&gt;  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index f9068af9de..1fe1b6b8e4 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv5] = &quot;Enable instructions for ARMv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv5] = &quot;armv4&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39; -march=armv5t${ARMPKGSFX_DSP}&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39;armv5:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv4.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 6c838e999c..adb9be8050 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv6hf&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv6] = &quot;Enable instructions for ARMv6&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv6] = &quot;armv4 armv5&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39; -march=armv6&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39;armv6:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index a2663d8008..09d2c03a5d 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= &quot;thumb&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7a] = &quot;Enable instructions for ARMv7-a&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7a] = &quot;armv4 armv5 armv6 armv7&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39; -march=armv7-a&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39;armv7a:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv6.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index 4d9260fecb..31e334f645 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv7vethf&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7ve] = &quot;Enable instructions for ARMv7ve&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7ve] = &quot;armv4 armv5 armv6 armv7 armv7a&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39; -march=armv7ve&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39;armv7ve:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv7a.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; index f27423cb2e..6e577697cc 100644<br>
&gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt; @@ -6,7 +6,7 @@ DEFAULTTUNE ?= &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[iwmmxt] = &quot;Enable Intel PXA27x specific processor optimizations&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -march=iwmmxt -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; +TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  AVAILTUNES += &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt;  ARMPKGARCH_tune-iwmmxt = &quot;iwmmxt&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt; 2.20.1<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt; &gt;&gt;&gt;&gt;&gt; Openembedded-core mailing list<br>
&gt; &gt;&gt;&gt;&gt;&gt; <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
&gt; &gt;&gt;&gt;&gt;&gt; <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
&gt;<br>
</div>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Jan. 26, 2019, 6:45 p.m. | #9
On Sat, Jan 26, 2019 at 9:39 AM Martin Jansa <martin.jansa@gmail.com> wrote:
>

> Which -mcpu/-march combination is causing issue in gcc9?


Its when using cortex-a5 tunes, -march=armv7-a -mcpu=cortex-a5, but if
we move the needle to fix the issue or test coverage then we miss the
point here, the fact that this keeps coming up means we have a
fundamental problem.

>

> I know we had this issue with armv7a tunes before, that's why I've added separate armv7ve before the switch from -mtune to -mcpu.

>


Thats fine, however as I have explained before -mcpu is a combination
of implicit -march and -mtune, so for best results should not be mixed
with them. Originally the tune design in OE is one to one if we used
-march + -mtune
method. That does not mean that -mcpu approach is inferior on the
contrary might be better in certain cases and in fact in majority of
cases we have.

> I still believe -mcpu (with or without -march) is better option.

>


I think on one hand it is, but there is another part which Mark
brought up of customized CPU implementations with not to common
choices of subsystems, which may not be exactly represented by -mcpu
options. I am inclined to
provide provisions to make it happen but I am not in favor of
designing it to address these corner implementations. I would rather
make it easy for 99% usecases.

> Using -mtune without indicating which -mtune was actually used in the package arch is bad (especially if you have multiple MACHINEs with different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending in armv7a package arch, unpacking all packages from sstate every time you switch MACHINE and the package manager on target never knowing which -mtune was used to build given package upgrade from feed).

>


Yes this was a change for better.

> Switching from -mcpu to -mtune while keeping the current cpu-specific package architectures is better, but then the use case, that I build everything e.g. with cortexa8 in -mtune and install this cortexa8 package feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime, but why not use generic armv7a DEFAULTTUNE to make it clear (to package manager as well as end user) that I'm not really optimizing for given CPU).

>


In current design I think we have design for using more optimized for
a CPU and be able to generate feeds which are cpu specific which is
great for certain use cases and hopefully more tunes to that CPU
implementation.

> From the naive openssl benchmarks I did few years back, there was very small difference between mtune/mcpu/just-march, but still for projects where I have separate package feeds for each device (e.g. LG TVs) I prefer to use -mcpu (because I really know that such packages won't ever be used on device with different CPU) and e.g. in LuneOS we're more concerned about package feed size and build time, so we select more generic DEFAULTTUNE which is shared across many MACHINEs and that doesn't have any -mcpu (nor -mtune) options in it, so should be fine as well.


Exactly, the point here, we will be best served if we make it one way
or other, e.g. raspbian used thumb1 ISA across all rpi implementations
and they can use same feeds across all RPis that have even existed. It
has advantages of
its own to be able to do that, especially for people who work on
higher stacks they would be happy with such a setup.

So I have to suggest on of three approached

1. Change -mcpu to -mtune and keep everything same. This make feed
arches point to tuned packages but fundamentally same for base
architecture ( e.g. armv7-a),
2. Just use -mcpu and do not use -march/-mtune and may be provide
mechanism to override -mcpu, which is done by packages anyway ( maps
directly to package architectures )
3. Just use -march and drop -mcpu and -mtune - Rename feed arches to
map to arch+features conventions instead of being CPU specific, this
will freak the users since it will be overwhelming to understand the
combinations
    e.g.  armv7ve+neon+vfpv4 etc. so the combination becomes
equivalent to -mcpu, current tune architecture we can construct this
easily by appending to march based on TUNE_FEATURES but I think
package arches will be a              massive to deal with and users
might ask what is this long -march/-mtune pointing to in terms of CPU,
but it will address Mark's usecase and will bring us closer to using
mcpu usecase, We can probaly do a bettter error reporting
    as well for conflicting tune features.

I can cook up patches for option 3 from tunes part, packaging part I
am not sure maybe we can live with what we have
option 2 I already have posted a patch, option 1 would be a simplest
patch of all which can be done quickly as well.

>

> We can easily extend the tune-test script I've used back then when switching to -mcpu to not only use bitbake -e, but also call gcc-cross to check for possible warnings from incompatible march/mcpu combinations and fix those. The old version is here:

> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test

> it was used in mcpu switch here:

> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test

> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3

>

> From the gcc git log I don't see many changes in:

> https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c

> nor

> https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in

> so I'm really interested which combination issues the warning now.

>

> Regards,

>

> On Sat, Jan 26, 2019 at 5:29 PM Khem Raj <raj.khem@gmail.com> wrote:

>>

>>

>> On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle <mark.hatle@windriver.com> wrote:

>> >

>> > On 1/24/19 9:22 PM, Khem Raj wrote:

>> > > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>> > >>

>> > >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

>> > >>>

>> > >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>> > >>>>

>> > >>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

>> > >>>>>

>> > >>>>> tune files which inherit the arch definitions already define appropriate

>> > >>>>> -mcpu option, which is equivalent of right -march and -mtune combination

>> > >>>>

>> > >>>> And what about machines which inherit an arch definition instead of a

>> > >>>> cpu definition? Is that no longer supported?

>> > >>>

>> > >>> I could not find such a machine configuration in several BSP layers I looked at.

>> > >>> Do you know of machine definitions where these files are included

>> > >>> directly in machine configs ?

>> > >>

>> > >> Using a CPU specific include but then leaving the generic DEFAULTTUNE

>> > >> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

>> > >> guess quite common.

>> > >

>> > > defaulttune does not play much part in appending -mcpu option to

>> > > compiler flags, A case

>> > > where this could bypass the setting mcpu is when we do not include a

>> > > tune-* for arm based machine

>> > > and thats the case I was interested to know.

>> > >

>> > > again if there is such a BSP I would be interested to test it out.

>> > >>

>> > >>> if so, then we have to either use _remove or introduce a weak variable

>> > >>> to set march only if

>> > >>> mcpu is not set which

>> > >>

>> > >> I think the solution is to ensure that the CPU specific tuning options

>> > >> are always compatible with any architecture specific options which may

>> > >> be active.

>> > >>

>> > >> In general our CPU specific tuning files are a little sloppy (e.g.

>> > >> defaulting to combinations of VFP versions and architecture levels

>> > >> which never exist in the real world). If newer versions of gcc are

>> > >> making those issues more apparent then why not take the opportunity to

>> > >> fix them properly?

>> > >

>> > > the mcpu option is helping with right march/mtune combination. while we can

>> > > use specific -march=arch(+-)features syntax and combine with right

>> > > -mtune to match -mcpu I think we should use

>> > > compiler defaults and not try to recreate something that -mcpu would

>> > > do it easily for us.

>> > >

>> > > So either we drop the idea of setting mcpu and use basic -march value

>> > > combined with -mtune ( which btw. was default in past)

>> > > or if we want to let compiler use ISA for a particular arch

>> > > implementation ( cortexXXX ) then we should just use -mcpu and drop

>> > > using -mtune and -march.

>> > >

>> > > I would include towards option 1.

>> >

>> > I know this is a bit of a 'me too' response, but we have to pick one format and

>> > stay with it.  Either option, but not both.

>>

>> I concur.

>>

>>

>> >

>> > -IF- we know that the appropriate -mcpu options are available for all of the

>> > potential combinations out there, then this is by far the preferred method in my

>> > mind.  Much easier to handle and manage...

>>

>> -mcpu options are available for known CPU implementations. But there always will

>> be weird ones, given how people can pick and choose subsystems for SOC on this

>> architecture, and its highly probable that they wont be in gcc. so real question we need to answer for is, should we design for those cases and how often does this often.

>>

>>

>> >

>> > However, the more complex route came out as various 'odd-ball' (and people claim

>> > don't exist, but they do) custom ARM cores get released without 'mandatory' math

>> > units, or some other odd ball variation.  (I've seen this numerous times over

>> > the last 20 years that something that doesn't exist, does... all because it's a

>> > custom part.)

>>

>> Yes, I am dealing with one such design even today

>>

>>

>> >

>> > If we have an easy way to define the -mcpu= means some magic combination of

>> > -march/-mtune within the GCC spec itself, then I'm 100% for moving to -mcpu to

>> > rid ourselves of this mess.. and then we still have the flexibility to easily

>> > update/add tunes and GCC configuration for the odd-balls that seem to crop up

>> > regularly.

>>

>> So yes we can do nearly same but not exactly same. We have to start adding or deleting

>> features via -march and -mtune would be same value, but there are cases where gcc defines

>> internal properties based on mcpu, that is not representable in those suffixes we will add. so

>> we will come very close but not exact and I think compiler is right in this case because we

>> are not exactly telling it about a CPU implementation, but we are telling the cpu has these properties, so it really may not be one of standard cpu implementation.

>>

>>

>> >

>> > (I know -I- can always patch GCC for new -mcpu combinations, but I'm not

>> > thinking about 'me', I'm thinking about the user of OE who is told 'use this

>> > CPU, it has this set of functions' and is NOT a compiler expert who can wade

>> > through GCC spec files and generate patches with any confidence.)

>> >

>>

>> I would think we can solve this for these niche cases, via using -march/-mtune and drop

>> -mcpu, we can append adding/deleting a given feature e.g. neon or vfp or vfpv3 etc.

>> but this would mean we have to rename our package feed names as well to match this

>> new representation, which currently is mapped to mcpu values. This is quite a departure

>> from package feeds point of view. but its more aligned with how we have defined arch and tunes.

>> so pick the battles.

>>

>>

>> > --Mark

>> >

>> > >>

>> > >>>>> and is preferred since gcc is getting stricter and stricter with option

>> > >>>>> check semantics and can now find incompatible -march and -mcpu options

>> > >>>>> better with every release. It does internal feature consistency check

>> > >>>>> and if it finds out discrepency between what -mcpu would expand to as

>> > >>>>> compared to -march it will flag the options to be incompatible, for

>> > >>>>> naked eye it sounds wrong but gcc would translate -mcpu to a given

>> > >>>>> -march internally and it might not match to what we set in these arch

>> > >>>>> files.

>> > >>>>>

>> > >>>>> The effects are quite subtle, where this can result in configure test

>> > >>>>> failing to compile due to these incompatible options and a feature

>> > >>>>> option getting disabled for a recipe for no reason.

>> > >>>>>

>> > >>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

>> > >>>>> -march=armv7-a are incompatible, many features in libstdc++ ends up

>> > >>>>> disabled due to configure check failures e.g. size_t size, ptrdiff_t

>> > >>>>> sizes, which inturn results in compiling libstdc++ with unwanted

>> > >>>>> disabled features.

>> > >>>>

>> > >>>> It would be interesting to see more specific details of this.

>> > >>>

>> > >>> These are configure tests which fail when -Werror is in use and is not

>> > >>> limited to libstdc++

>> > >>> it can happen in any package. Since the diagnostic about incompatible

>> > >>> march mcpu pair

>> > >>> is a warning in general, it does not matter, but when we have -Werror

>> > >>> enabled this turns

>> > >>> into error, You can simply try a small helloworld example to see the effects.

>> > >>>

>> > >>>>

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

>> > >>>>> ---

>> > >>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

>> > >>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

>> > >>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

>> > >>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

>> > >>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

>> > >>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

>> > >>>>>

>> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

>> > >>>>> index 47a7ad2830..52d8ab1e8f 100644

>> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

>> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

>> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

>> > >>>>>

>> > >>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

>> > >>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

>> > >>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

>> > >>>>>  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

>> > >>>>>  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

>> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

>> > >>>>> index f9068af9de..1fe1b6b8e4 100644

>> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

>> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

>> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

>> > >>>>>

>> > >>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

>> > >>>>>  TUNECONFLICTS[armv5] = "armv4"

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

>> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

>> > >>>>>

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

>> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

>> > >>>>> index 6c838e999c..adb9be8050 100644

>> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

>> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

>> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

>> > >>>>>

>> > >>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

>> > >>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

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

>> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

>> > >>>>>

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

>> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

>> > >>>>> index a2663d8008..09d2c03a5d 100644

>> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

>> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

>> > >>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

>> > >>>>>

>> > >>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

>> > >>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

>> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

>> > >>>>>

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

>> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

>> > >>>>> index 4d9260fecb..31e334f645 100644

>> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

>> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

>> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

>> > >>>>>

>> > >>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

>> > >>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

>> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

>> > >>>>>

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

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

>> > >>>>> index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

>> > >>>>>

>> > >>>>>  AVAILTUNES += "iwmmxt"

>> > >>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>> > >>>>> --

>> > >>>>> 2.20.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

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Martin Jansa Jan. 26, 2019, 9:04 p.m. | #10
>  2. Just use -mcpu and do not use -march/-mtune and may be

provide mechanism to override -mcpu, which is done by packages anyway (
maps directly to package architectures )

This would be my preferred solution, I know that tune files are already
quite complicated, but another variable which will hold either just march
(for more generic DEFAULTTUNEs as Andre reported) or mcpu (for DEFAULTTUNEs
targeting specific cpu) or possibly mtune as well (if someone really wants
and overrides this variable in his DISTRO) doesn't make it much more
complicated and should work fine for everybody.



On Sat, Jan 26, 2019 at 7:45 PM Khem Raj <raj.khem@gmail.com> wrote:

> On Sat, Jan 26, 2019 at 9:39 AM Martin Jansa <martin.jansa@gmail.com>

> wrote:

> >

> > Which -mcpu/-march combination is causing issue in gcc9?

>

> Its when using cortex-a5 tunes, -march=armv7-a -mcpu=cortex-a5, but if

> we move the needle to fix the issue or test coverage then we miss the

> point here, the fact that this keeps coming up means we have a

> fundamental problem.

>

> >

> > I know we had this issue with armv7a tunes before, that's why I've added

> separate armv7ve before the switch from -mtune to -mcpu.

> >

>

> Thats fine, however as I have explained before -mcpu is a combination

> of implicit -march and -mtune, so for best results should not be mixed

> with them. Originally the tune design in OE is one to one if we used

> -march + -mtune

> method. That does not mean that -mcpu approach is inferior on the

> contrary might be better in certain cases and in fact in majority of

> cases we have.

>

> > I still believe -mcpu (with or without -march) is better option.

> >

>

> I think on one hand it is, but there is another part which Mark

> brought up of customized CPU implementations with not to common

> choices of subsystems, which may not be exactly represented by -mcpu

> options. I am inclined to

> provide provisions to make it happen but I am not in favor of

> designing it to address these corner implementations. I would rather

> make it easy for 99% usecases.

>

> > Using -mtune without indicating which -mtune was actually used in the

> package arch is bad (especially if you have multiple MACHINEs with

> different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending

> in armv7a package arch, unpacking all packages from sstate every time you

> switch MACHINE and the package manager on target never knowing which -mtune

> was used to build given package upgrade from feed).

> >

>

> Yes this was a change for better.

>

> > Switching from -mcpu to -mtune while keeping the current cpu-specific

> package architectures is better, but then the use case, that I build

> everything e.g. with cortexa8 in -mtune and install this cortexa8 package

> feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime,

> but why not use generic armv7a DEFAULTTUNE to make it clear (to package

> manager as well as end user) that I'm not really optimizing for given CPU).

> >

>

> In current design I think we have design for using more optimized for

> a CPU and be able to generate feeds which are cpu specific which is

> great for certain use cases and hopefully more tunes to that CPU

> implementation.

>

> > From the naive openssl benchmarks I did few years back, there was very

> small difference between mtune/mcpu/just-march, but still for projects

> where I have separate package feeds for each device (e.g. LG TVs) I prefer

> to use -mcpu (because I really know that such packages won't ever be used

> on device with different CPU) and e.g. in LuneOS we're more concerned about

> package feed size and build time, so we select more generic DEFAULTTUNE

> which is shared across many MACHINEs and that doesn't have any -mcpu (nor

> -mtune) options in it, so should be fine as well.

>

> Exactly, the point here, we will be best served if we make it one way

> or other, e.g. raspbian used thumb1 ISA across all rpi implementations

> and they can use same feeds across all RPis that have even existed. It

> has advantages of

> its own to be able to do that, especially for people who work on

> higher stacks they would be happy with such a setup.

>

> So I have to suggest on of three approached

>

> 1. Change -mcpu to -mtune and keep everything same. This make feed

> arches point to tuned packages but fundamentally same for base

> architecture ( e.g. armv7-a),

> 2. Just use -mcpu and do not use -march/-mtune and may be provide

> mechanism to override -mcpu, which is done by packages anyway ( maps

> directly to package architectures )

> 3. Just use -march and drop -mcpu and -mtune - Rename feed arches to

> map to arch+features conventions instead of being CPU specific, this

> will freak the users since it will be overwhelming to understand the

> combinations

>     e.g.  armv7ve+neon+vfpv4 etc. so the combination becomes

> equivalent to -mcpu, current tune architecture we can construct this

> easily by appending to march based on TUNE_FEATURES but I think

> package arches will be a              massive to deal with and users

> might ask what is this long -march/-mtune pointing to in terms of CPU,

> but it will address Mark's usecase and will bring us closer to using

> mcpu usecase, We can probaly do a bettter error reporting

>     as well for conflicting tune features.

>

> I can cook up patches for option 3 from tunes part, packaging part I

> am not sure maybe we can live with what we have

> option 2 I already have posted a patch, option 1 would be a simplest

> patch of all which can be done quickly as well.

>

> >

> > We can easily extend the tune-test script I've used back then when

> switching to -mcpu to not only use bitbake -e, but also call gcc-cross to

> check for possible warnings from incompatible march/mcpu combinations and

> fix those. The old version is here:

> >

> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test

> > it was used in mcpu switch here:

> >

> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test

> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3

> >

> > From the gcc git log I don't see many changes in:

> >

> https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c

> > nor

> >

> https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in

> > so I'm really interested which combination issues the warning now.

> >

> > Regards,

> >

> > On Sat, Jan 26, 2019 at 5:29 PM Khem Raj <raj.khem@gmail.com> wrote:

> >>

> >>

> >> On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle <mark.hatle@windriver.com>

> wrote:

> >> >

> >> > On 1/24/19 9:22 PM, Khem Raj wrote:

> >> > > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com>

> wrote:

> >> > >>

> >> > >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com>

> wrote:

> >> > >>>

> >> > >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <

> armccurdy@gmail.com> wrote:

> >> > >>>>

> >> > >>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com>

> wrote:

> >> > >>>>>

> >> > >>>>> tune files which inherit the arch definitions already define

> appropriate

> >> > >>>>> -mcpu option, which is equivalent of right -march and -mtune

> combination

> >> > >>>>

> >> > >>>> And what about machines which inherit an arch definition instead

> of a

> >> > >>>> cpu definition? Is that no longer supported?

> >> > >>>

> >> > >>> I could not find such a machine configuration in several BSP

> layers I looked at.

> >> > >>> Do you know of machine definitions where these files are included

> >> > >>> directly in machine configs ?

> >> > >>

> >> > >> Using a CPU specific include but then leaving the generic

> DEFAULTTUNE

> >> > >> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

> >> > >> guess quite common.

> >> > >

> >> > > defaulttune does not play much part in appending -mcpu option to

> >> > > compiler flags, A case

> >> > > where this could bypass the setting mcpu is when we do not include a

> >> > > tune-* for arm based machine

> >> > > and thats the case I was interested to know.

> >> > >

> >> > > again if there is such a BSP I would be interested to test it out.

> >> > >>

> >> > >>> if so, then we have to either use _remove or introduce a weak

> variable

> >> > >>> to set march only if

> >> > >>> mcpu is not set which

> >> > >>

> >> > >> I think the solution is to ensure that the CPU specific tuning

> options

> >> > >> are always compatible with any architecture specific options which

> may

> >> > >> be active.

> >> > >>

> >> > >> In general our CPU specific tuning files are a little sloppy (e.g.

> >> > >> defaulting to combinations of VFP versions and architecture levels

> >> > >> which never exist in the real world). If newer versions of gcc are

> >> > >> making those issues more apparent then why not take the

> opportunity to

> >> > >> fix them properly?

> >> > >

> >> > > the mcpu option is helping with right march/mtune combination.

> while we can

> >> > > use specific -march=arch(+-)features syntax and combine with right

> >> > > -mtune to match -mcpu I think we should use

> >> > > compiler defaults and not try to recreate something that -mcpu would

> >> > > do it easily for us.

> >> > >

> >> > > So either we drop the idea of setting mcpu and use basic -march

> value

> >> > > combined with -mtune ( which btw. was default in past)

> >> > > or if we want to let compiler use ISA for a particular arch

> >> > > implementation ( cortexXXX ) then we should just use -mcpu and drop

> >> > > using -mtune and -march.

> >> > >

> >> > > I would include towards option 1.

> >> >

> >> > I know this is a bit of a 'me too' response, but we have to pick one

> format and

> >> > stay with it.  Either option, but not both.

> >>

> >> I concur.

> >>

> >>

> >> >

> >> > -IF- we know that the appropriate -mcpu options are available for all

> of the

> >> > potential combinations out there, then this is by far the preferred

> method in my

> >> > mind.  Much easier to handle and manage...

> >>

> >> -mcpu options are available for known CPU implementations. But there

> always will

> >> be weird ones, given how people can pick and choose subsystems for SOC

> on this

> >> architecture, and its highly probable that they wont be in gcc. so real

> question we need to answer for is, should we design for those cases and how

> often does this often.

> >>

> >>

> >> >

> >> > However, the more complex route came out as various 'odd-ball' (and

> people claim

> >> > don't exist, but they do) custom ARM cores get released without

> 'mandatory' math

> >> > units, or some other odd ball variation.  (I've seen this numerous

> times over

> >> > the last 20 years that something that doesn't exist, does... all

> because it's a

> >> > custom part.)

> >>

> >> Yes, I am dealing with one such design even today

> >>

> >>

> >> >

> >> > If we have an easy way to define the -mcpu= means some magic

> combination of

> >> > -march/-mtune within the GCC spec itself, then I'm 100% for moving to

> -mcpu to

> >> > rid ourselves of this mess.. and then we still have the flexibility

> to easily

> >> > update/add tunes and GCC configuration for the odd-balls that seem to

> crop up

> >> > regularly.

> >>

> >> So yes we can do nearly same but not exactly same. We have to start

> adding or deleting

> >> features via -march and -mtune would be same value, but there are cases

> where gcc defines

> >> internal properties based on mcpu, that is not representable in those

> suffixes we will add. so

> >> we will come very close but not exact and I think compiler is right in

> this case because we

> >> are not exactly telling it about a CPU implementation, but we are

> telling the cpu has these properties, so it really may not be one of

> standard cpu implementation.

> >>

> >>

> >> >

> >> > (I know -I- can always patch GCC for new -mcpu combinations, but I'm

> not

> >> > thinking about 'me', I'm thinking about the user of OE who is told

> 'use this

> >> > CPU, it has this set of functions' and is NOT a compiler expert who

> can wade

> >> > through GCC spec files and generate patches with any confidence.)

> >> >

> >>

> >> I would think we can solve this for these niche cases, via using

> -march/-mtune and drop

> >> -mcpu, we can append adding/deleting a given feature e.g. neon or vfp

> or vfpv3 etc.

> >> but this would mean we have to rename our package feed names as well to

> match this

> >> new representation, which currently is mapped to mcpu values. This is

> quite a departure

> >> from package feeds point of view. but its more aligned with how we have

> defined arch and tunes.

> >> so pick the battles.

> >>

> >>

> >> > --Mark

> >> >

> >> > >>

> >> > >>>>> and is preferred since gcc is getting stricter and stricter

> with option

> >> > >>>>> check semantics and can now find incompatible -march and -mcpu

> options

> >> > >>>>> better with every release. It does internal feature consistency

> check

> >> > >>>>> and if it finds out discrepency between what -mcpu would expand

> to as

> >> > >>>>> compared to -march it will flag the options to be incompatible,

> for

> >> > >>>>> naked eye it sounds wrong but gcc would translate -mcpu to a

> given

> >> > >>>>> -march internally and it might not match to what we set in

> these arch

> >> > >>>>> files.

> >> > >>>>>

> >> > >>>>> The effects are quite subtle, where this can result in

> configure test

> >> > >>>>> failing to compile due to these incompatible options and a

> feature

> >> > >>>>> option getting disabled for a recipe for no reason.

> >> > >>>>>

> >> > >>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

> >> > >>>>> -march=armv7-a are incompatible, many features in libstdc++

> ends up

> >> > >>>>> disabled due to configure check failures e.g. size_t size,

> ptrdiff_t

> >> > >>>>> sizes, which inturn results in compiling libstdc++ with unwanted

> >> > >>>>> disabled features.

> >> > >>>>

> >> > >>>> It would be interesting to see more specific details of this.

> >> > >>>

> >> > >>> These are configure tests which fail when -Werror is in use and

> is not

> >> > >>> limited to libstdc++

> >> > >>> it can happen in any package. Since the diagnostic about

> incompatible

> >> > >>> march mcpu pair

> >> > >>> is a warning in general, it does not matter, but when we have

> -Werror

> >> > >>> enabled this turns

> >> > >>> into error, You can simply try a small helloworld example to see

> the effects.

> >> > >>>

> >> > >>>>

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

> >> > >>>>> ---

> >> > >>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

> >> > >>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

> >> > >>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

> >> > >>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

> >> > >>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

> >> > >>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

> >> > >>>>>

> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc

> b/meta/conf/machine/include/arm/arch-armv4.inc

> >> > >>>>> index 47a7ad2830..52d8ab1e8f 100644

> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

> >> > >>>>>

> >> > >>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

> >> > >>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

> >> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4',

> ' -march=armv4t', '', d)}"

> >> > >>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but

> then disable it when we have also armv5 or thumb

> >> > >>>>>  # maybe we should extend bb.utils.contains to support check

> for any checkvalues in value, now it does

> >> > >>>>>  # checkvalues.issubset(val) which cannot be used for negative

> test of foo neither bar in value

> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc

> b/meta/conf/machine/include/arm/arch-armv5.inc

> >> > >>>>> index f9068af9de..1fe1b6b8e4 100644

> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

> >> > >>>>>

> >> > >>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

> >> > >>>>>  TUNECONFLICTS[armv5] = "armv4"

> >> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5',

> ' -march=armv5t${ARMPKGSFX_DSP}', '', d)}"

> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv5', 'armv5:', '' ,d)}"

> >> > >>>>>

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

> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc

> b/meta/conf/machine/include/arm/arch-armv6.inc

> >> > >>>>> index 6c838e999c..adb9be8050 100644

> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

> >> > >>>>>

> >> > >>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

> >> > >>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

> >> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6',

> ' -march=armv6', '', d)}"

> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv6', 'armv6:', '' ,d)}"

> >> > >>>>>

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

> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc

> b/meta/conf/machine/include/arm/arch-armv7a.inc

> >> > >>>>> index a2663d8008..09d2c03a5d 100644

> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

> >> > >>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

> >> > >>>>>

> >> > >>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

> >> > >>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

> >> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7a', ' -march=armv7-a', '', d)}"

> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7a', 'armv7a:', '' ,d)}"

> >> > >>>>>

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

> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc

> b/meta/conf/machine/include/arm/arch-armv7ve.inc

> >> > >>>>> index 4d9260fecb..31e334f645 100644

> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

> >> > >>>>>

> >> > >>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

> >> > >>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

> >> > >>>>> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7ve', ' -march=armv7ve', '', d)}"

> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',

> 'armv7ve', 'armv7ve:', '' ,d)}"

> >> > >>>>>

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

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

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

> >> > >>>>> index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

> >> > >>>>>

> >> > >>>>>  AVAILTUNES += "iwmmxt"

> >> > >>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

> >> > >>>>> --

> >> > >>>>> 2.20.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

>
<div dir="ltr">&gt; 

2. Just use -mcpu and do not use -march/-mtune and may be provide mechanism to override -mcpu, which is done by packages anyway ( maps directly to package architectures )<div><br></div><div>This would be my preferred solution, I know that tune files are already quite complicated, but another variable which will hold either just march (for more generic DEFAULTTUNEs as Andre reported) or mcpu (for DEFAULTTUNEs targeting specific cpu) or possibly mtune as well (if someone really wants and overrides this variable in his DISTRO) doesn&#39;t make it much more complicated and should work fine for everybody.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 26, 2019 at 7:45 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jan 26, 2019 at 9:39 AM Martin Jansa &lt;<a href="mailto:martin.jansa@gmail.com" target="_blank">martin.jansa@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Which -mcpu/-march combination is causing issue in gcc9?<br>
<br>
Its when using cortex-a5 tunes, -march=armv7-a -mcpu=cortex-a5, but if<br>
we move the needle to fix the issue or test coverage then we miss the<br>
point here, the fact that this keeps coming up means we have a<br>
fundamental problem.<br>
<br>
&gt;<br>
&gt; I know we had this issue with armv7a tunes before, that&#39;s why I&#39;ve added separate armv7ve before the switch from -mtune to -mcpu.<br>
&gt;<br>
<br>
Thats fine, however as I have explained before -mcpu is a combination<br>
of implicit -march and -mtune, so for best results should not be mixed<br>
with them. Originally the tune design in OE is one to one if we used<br>
-march + -mtune<br>
method. That does not mean that -mcpu approach is inferior on the<br>
contrary might be better in certain cases and in fact in majority of<br>
cases we have.<br>
<br>
&gt; I still believe -mcpu (with or without -march) is better option.<br>
&gt;<br>
<br>
I think on one hand it is, but there is another part which Mark<br>
brought up of customized CPU implementations with not to common<br>
choices of subsystems, which may not be exactly represented by -mcpu<br>
options. I am inclined to<br>
provide provisions to make it happen but I am not in favor of<br>
designing it to address these corner implementations. I would rather<br>
make it easy for 99% usecases.<br>
<br>
&gt; Using -mtune without indicating which -mtune was actually used in the package arch is bad (especially if you have multiple MACHINEs with different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending in armv7a package arch, unpacking all packages from sstate every time you switch MACHINE and the package manager on target never knowing which -mtune was used to build given package upgrade from feed).<br>
&gt;<br>
<br>
Yes this was a change for better.<br>
<br>
&gt; Switching from -mcpu to -mtune while keeping the current cpu-specific package architectures is better, but then the use case, that I build everything e.g. with cortexa8 in -mtune and install this cortexa8 package feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime, but why not use generic armv7a DEFAULTTUNE to make it clear (to package manager as well as end user) that I&#39;m not really optimizing for given CPU).<br>
&gt;<br>
<br>
In current design I think we have design for using more optimized for<br>
a CPU and be able to generate feeds which are cpu specific which is<br>
great for certain use cases and hopefully more tunes to that CPU<br>
implementation.<br>
<br>
&gt; From the naive openssl benchmarks I did few years back, there was very small difference between mtune/mcpu/just-march, but still for projects where I have separate package feeds for each device (e.g. LG TVs) I prefer to use -mcpu (because I really know that such packages won&#39;t ever be used on device with different CPU) and e.g. in LuneOS we&#39;re more concerned about package feed size and build time, so we select more generic DEFAULTTUNE which is shared across many MACHINEs and that doesn&#39;t have any -mcpu (nor -mtune) options in it, so should be fine as well.<br>
<br>
Exactly, the point here, we will be best served if we make it one way<br>
or other, e.g. raspbian used thumb1 ISA across all rpi implementations<br>
and they can use same feeds across all RPis that have even existed. It<br>
has advantages of<br>
its own to be able to do that, especially for people who work on<br>
higher stacks they would be happy with such a setup.<br>
<br>
So I have to suggest on of three approached<br>
<br>
1. Change -mcpu to -mtune and keep everything same. This make feed<br>
arches point to tuned packages but fundamentally same for base<br>
architecture ( e.g. armv7-a),<br>
2. Just use -mcpu and do not use -march/-mtune and may be provide<br>
mechanism to override -mcpu, which is done by packages anyway ( maps<br>
directly to package architectures )<br>
3. Just use -march and drop -mcpu and -mtune - Rename feed arches to<br>
map to arch+features conventions instead of being CPU specific, this<br>
will freak the users since it will be overwhelming to understand the<br>
combinations<br>
    e.g.  armv7ve+neon+vfpv4 etc. so the combination becomes<br>
equivalent to -mcpu, current tune architecture we can construct this<br>
easily by appending to march based on TUNE_FEATURES but I think<br>
package arches will be a              massive to deal with and users<br>
might ask what is this long -march/-mtune pointing to in terms of CPU,<br>
but it will address Mark&#39;s usecase and will bring us closer to using<br>
mcpu usecase, We can probaly do a bettter error reporting<br>
    as well for conflicting tune features.<br>
<br>
I can cook up patches for option 3 from tunes part, packaging part I<br>
am not sure maybe we can live with what we have<br>
option 2 I already have posted a patch, option 1 would be a simplest<br>
patch of all which can be done quickly as well.<br>
<br>
&gt;<br>
&gt; We can easily extend the tune-test script I&#39;ve used back then when switching to -mcpu to not only use bitbake -e, but also call gcc-cross to check for possible warnings from incompatible march/mcpu combinations and fix those. The old version is here:<br>
&gt; <a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test</a><br>
&gt; it was used in mcpu switch here:<br>
&gt; <a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test</a><br>
&gt; <a href="http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3" rel="noreferrer" target="_blank">http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3</a><br>
&gt;<br>
&gt; From the gcc git log I don&#39;t see many changes in:<br>
&gt; <a href="https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c" rel="noreferrer" target="_blank">https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c</a><br>
&gt; nor<br>
&gt; <a href="https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in" rel="noreferrer" target="_blank">https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in</a><br>
&gt; so I&#39;m really interested which combination issues the warning now.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; On Sat, Jan 26, 2019 at 5:29 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle &lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On 1/24/19 9:22 PM, Khem Raj wrote:<br>
&gt;&gt; &gt; &gt; On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; On Wed, Jan 23, 2019 at 2:50 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt; On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt; On Wed, Jan 23, 2019 at 12:05 PM Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; tune files which inherit the arch definitions already define appropriate<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -mcpu option, which is equivalent of right -march and -mtune combination<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt; And what about machines which inherit an arch definition instead of a<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt; cpu definition? Is that no longer supported?<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt; I could not find such a machine configuration in several BSP layers I looked at.<br>
&gt;&gt; &gt; &gt;&gt;&gt; Do you know of machine definitions where these files are included<br>
&gt;&gt; &gt; &gt;&gt;&gt; directly in machine configs ?<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; Using a CPU specific include but then leaving the generic DEFAULTTUNE<br>
&gt;&gt; &gt; &gt;&gt; (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I<br>
&gt;&gt; &gt; &gt;&gt; guess quite common.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; defaulttune does not play much part in appending -mcpu option to<br>
&gt;&gt; &gt; &gt; compiler flags, A case<br>
&gt;&gt; &gt; &gt; where this could bypass the setting mcpu is when we do not include a<br>
&gt;&gt; &gt; &gt; tune-* for arm based machine<br>
&gt;&gt; &gt; &gt; and thats the case I was interested to know.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; again if there is such a BSP I would be interested to test it out.<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt; if so, then we have to either use _remove or introduce a weak variable<br>
&gt;&gt; &gt; &gt;&gt;&gt; to set march only if<br>
&gt;&gt; &gt; &gt;&gt;&gt; mcpu is not set which<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; I think the solution is to ensure that the CPU specific tuning options<br>
&gt;&gt; &gt; &gt;&gt; are always compatible with any architecture specific options which may<br>
&gt;&gt; &gt; &gt;&gt; be active.<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; In general our CPU specific tuning files are a little sloppy (e.g.<br>
&gt;&gt; &gt; &gt;&gt; defaulting to combinations of VFP versions and architecture levels<br>
&gt;&gt; &gt; &gt;&gt; which never exist in the real world). If newer versions of gcc are<br>
&gt;&gt; &gt; &gt;&gt; making those issues more apparent then why not take the opportunity to<br>
&gt;&gt; &gt; &gt;&gt; fix them properly?<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; the mcpu option is helping with right march/mtune combination. while we can<br>
&gt;&gt; &gt; &gt; use specific -march=arch(+-)features syntax and combine with right<br>
&gt;&gt; &gt; &gt; -mtune to match -mcpu I think we should use<br>
&gt;&gt; &gt; &gt; compiler defaults and not try to recreate something that -mcpu would<br>
&gt;&gt; &gt; &gt; do it easily for us.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; So either we drop the idea of setting mcpu and use basic -march value<br>
&gt;&gt; &gt; &gt; combined with -mtune ( which btw. was default in past)<br>
&gt;&gt; &gt; &gt; or if we want to let compiler use ISA for a particular arch<br>
&gt;&gt; &gt; &gt; implementation ( cortexXXX ) then we should just use -mcpu and drop<br>
&gt;&gt; &gt; &gt; using -mtune and -march.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; I would include towards option 1.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I know this is a bit of a &#39;me too&#39; response, but we have to pick one format and<br>
&gt;&gt; &gt; stay with it.  Either option, but not both.<br>
&gt;&gt;<br>
&gt;&gt; I concur.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -IF- we know that the appropriate -mcpu options are available for all of the<br>
&gt;&gt; &gt; potential combinations out there, then this is by far the preferred method in my<br>
&gt;&gt; &gt; mind.  Much easier to handle and manage...<br>
&gt;&gt;<br>
&gt;&gt; -mcpu options are available for known CPU implementations. But there always will<br>
&gt;&gt; be weird ones, given how people can pick and choose subsystems for SOC on this<br>
&gt;&gt; architecture, and its highly probable that they wont be in gcc. so real question we need to answer for is, should we design for those cases and how often does this often.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; However, the more complex route came out as various &#39;odd-ball&#39; (and people claim<br>
&gt;&gt; &gt; don&#39;t exist, but they do) custom ARM cores get released without &#39;mandatory&#39; math<br>
&gt;&gt; &gt; units, or some other odd ball variation.  (I&#39;ve seen this numerous times over<br>
&gt;&gt; &gt; the last 20 years that something that doesn&#39;t exist, does... all because it&#39;s a<br>
&gt;&gt; &gt; custom part.)<br>
&gt;&gt;<br>
&gt;&gt; Yes, I am dealing with one such design even today<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If we have an easy way to define the -mcpu= means some magic combination of<br>
&gt;&gt; &gt; -march/-mtune within the GCC spec itself, then I&#39;m 100% for moving to -mcpu to<br>
&gt;&gt; &gt; rid ourselves of this mess.. and then we still have the flexibility to easily<br>
&gt;&gt; &gt; update/add tunes and GCC configuration for the odd-balls that seem to crop up<br>
&gt;&gt; &gt; regularly.<br>
&gt;&gt;<br>
&gt;&gt; So yes we can do nearly same but not exactly same. We have to start adding or deleting<br>
&gt;&gt; features via -march and -mtune would be same value, but there are cases where gcc defines<br>
&gt;&gt; internal properties based on mcpu, that is not representable in those suffixes we will add. so<br>
&gt;&gt; we will come very close but not exact and I think compiler is right in this case because we<br>
&gt;&gt; are not exactly telling it about a CPU implementation, but we are telling the cpu has these properties, so it really may not be one of standard cpu implementation.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; (I know -I- can always patch GCC for new -mcpu combinations, but I&#39;m not<br>
&gt;&gt; &gt; thinking about &#39;me&#39;, I&#39;m thinking about the user of OE who is told &#39;use this<br>
&gt;&gt; &gt; CPU, it has this set of functions&#39; and is NOT a compiler expert who can wade<br>
&gt;&gt; &gt; through GCC spec files and generate patches with any confidence.)<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; I would think we can solve this for these niche cases, via using -march/-mtune and drop<br>
&gt;&gt; -mcpu, we can append adding/deleting a given feature e.g. neon or vfp or vfpv3 etc.<br>
&gt;&gt; but this would mean we have to rename our package feed names as well to match this<br>
&gt;&gt; new representation, which currently is mapped to mcpu values. This is quite a departure<br>
&gt;&gt; from package feeds point of view. but its more aligned with how we have defined arch and tunes.<br>
&gt;&gt; so pick the battles.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; --Mark<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; and is preferred since gcc is getting stricter and stricter with option<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; check semantics and can now find incompatible -march and -mcpu options<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; better with every release. It does internal feature consistency check<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; and if it finds out discrepency between what -mcpu would expand to as<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; compared to -march it will flag the options to be incompatible, for<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; naked eye it sounds wrong but gcc would translate -mcpu to a given<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -march internally and it might not match to what we set in these arch<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; files.<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; The effects are quite subtle, where this can result in configure test<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; failing to compile due to these incompatible options and a feature<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; option getting disabled for a recipe for no reason.<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -march=armv7-a are incompatible, many features in libstdc++ ends up<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; disabled due to configure check failures e.g. size_t size, ptrdiff_t<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; sizes, which inturn results in compiling libstdc++ with unwanted<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; disabled features.<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt; It would be interesting to see more specific details of this.<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt; These are configure tests which fail when -Werror is in use and is not<br>
&gt;&gt; &gt; &gt;&gt;&gt; limited to libstdc++<br>
&gt;&gt; &gt; &gt;&gt;&gt; it can happen in any package. Since the diagnostic about incompatible<br>
&gt;&gt; &gt; &gt;&gt;&gt; march mcpu pair<br>
&gt;&gt; &gt; &gt;&gt;&gt; is a warning in general, it does not matter, but when we have -Werror<br>
&gt;&gt; &gt; &gt;&gt;&gt; enabled this turns<br>
&gt;&gt; &gt; &gt;&gt;&gt; into error, You can simply try a small helloworld example to see the effects.<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; Signed-off-by: Khem Raj &lt;<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; ---<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  meta/conf/machine/include/tune-iwmmxt.inc      | 2 +-<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  6 files changed, 1 insertion(+), 6 deletions(-)<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index 47a7ad2830..52d8ab1e8f 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv4.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv4&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[arm] = &quot;Enable ARM instruction set&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv4] = &quot;Enable instructions for ARMv4&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv4&#39;, &#39; -march=armv4t&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index f9068af9de..1fe1b6b8e4 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv5.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv5&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv5] = &quot;Enable instructions for ARMv5&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv5] = &quot;armv4&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39; -march=armv5t${ARMPKGSFX_DSP}&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv5&#39;, &#39;armv5:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv4.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index 6c838e999c..adb9be8050 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv6.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv6hf&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv6] = &quot;Enable instructions for ARMv6&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv6] = &quot;armv4 armv5&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39; -march=armv6&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv6&#39;, &#39;armv6:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index a2663d8008..09d2c03a5d 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7a.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= &quot;thumb&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7a] = &quot;Enable instructions for ARMv7-a&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7a] = &quot;armv4 armv5 armv6 armv7&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39; -march=armv7-a&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7a&#39;, &#39;armv7a:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv6.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index 4d9260fecb..31e334f645 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -2,7 +2,6 @@ DEFAULTTUNE ?= &quot;armv7vethf&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[armv7ve] = &quot;Enable instructions for ARMv7ve&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNECONFLICTS[armv7ve] = &quot;armv4 armv5 armv6 armv7 armv7a&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39; -march=armv7ve&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  MACHINEOVERRIDES =. &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;armv7ve&#39;, &#39;armv7ve:&#39;, &#39;&#39; ,d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv7a.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; index f27423cb2e..6e577697cc 100644<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --- a/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +++ b/meta/conf/machine/include/tune-iwmmxt.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; @@ -6,7 +6,7 @@ DEFAULTTUNE ?= &quot;iwmmxt&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  require conf/machine/include/arm/arch-armv5-dsp.inc<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  TUNEVALID[iwmmxt] = &quot;Enable Intel PXA27x specific processor optimizations&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; -TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -march=iwmmxt -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; +TUNE_CCARGS .= &quot;${@bb.utils.contains(&#39;TUNE_FEATURES&#39;, &#39;iwmmxt&#39;, &#39; -mcpu=iwmmxt&#39;, &#39;&#39;, d)}&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  AVAILTUNES += &quot;iwmmxt&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;  ARMPKGARCH_tune-iwmmxt = &quot;iwmmxt&quot;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; 2.20.1<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; Openembedded-core mailing list<br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
&gt;&gt; &gt; &gt;&gt;&gt;&gt;&gt; <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; --<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Openembedded-core mailing list<br>
&gt;&gt; <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
&gt;&gt; <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Jan. 26, 2019, 9:06 p.m. | #11
On Sat, Jan 26, 2019 at 1:04 PM Martin Jansa <martin.jansa@gmail.com> wrote:
>

> >  2. Just use -mcpu and do not use -march/-mtune and may be provide mechanism to override -mcpu, which is done by packages anyway ( maps directly to package architectures )

>

> This would be my preferred solution, I know that tune files are already quite complicated, but another variable which will hold either just march (for more generic DEFAULTTUNEs as Andre reported) or mcpu (for DEFAULTTUNEs targeting specific cpu) or possibly mtune as well (if someone really wants and overrides this variable in his DISTRO) doesn't make it much more complicated and should work fine for everybody.


is it something that does this fine ?
https://patchwork.openembedded.org/patch/158189/

>

>

>

> On Sat, Jan 26, 2019 at 7:45 PM Khem Raj <raj.khem@gmail.com> wrote:

>>

>> On Sat, Jan 26, 2019 at 9:39 AM Martin Jansa <martin.jansa@gmail.com> wrote:

>> >

>> > Which -mcpu/-march combination is causing issue in gcc9?

>>

>> Its when using cortex-a5 tunes, -march=armv7-a -mcpu=cortex-a5, but if

>> we move the needle to fix the issue or test coverage then we miss the

>> point here, the fact that this keeps coming up means we have a

>> fundamental problem.

>>

>> >

>> > I know we had this issue with armv7a tunes before, that's why I've added separate armv7ve before the switch from -mtune to -mcpu.

>> >

>>

>> Thats fine, however as I have explained before -mcpu is a combination

>> of implicit -march and -mtune, so for best results should not be mixed

>> with them. Originally the tune design in OE is one to one if we used

>> -march + -mtune

>> method. That does not mean that -mcpu approach is inferior on the

>> contrary might be better in certain cases and in fact in majority of

>> cases we have.

>>

>> > I still believe -mcpu (with or without -march) is better option.

>> >

>>

>> I think on one hand it is, but there is another part which Mark

>> brought up of customized CPU implementations with not to common

>> choices of subsystems, which may not be exactly represented by -mcpu

>> options. I am inclined to

>> provide provisions to make it happen but I am not in favor of

>> designing it to address these corner implementations. I would rather

>> make it easy for 99% usecases.

>>

>> > Using -mtune without indicating which -mtune was actually used in the package arch is bad (especially if you have multiple MACHINEs with different DEFAULTTUNEs e.g. cortexa7, cortexa8 in -mtune, but both ending in armv7a package arch, unpacking all packages from sstate every time you switch MACHINE and the package manager on target never knowing which -mtune was used to build given package upgrade from feed).

>> >

>>

>> Yes this was a change for better.

>>

>> > Switching from -mcpu to -mtune while keeping the current cpu-specific package architectures is better, but then the use case, that I build everything e.g. with cortexa8 in -mtune and install this cortexa8 package feed on cortexa7 MACHINEs also looks strange, yes it will work in runtime, but why not use generic armv7a DEFAULTTUNE to make it clear (to package manager as well as end user) that I'm not really optimizing for given CPU).

>> >

>>

>> In current design I think we have design for using more optimized for

>> a CPU and be able to generate feeds which are cpu specific which is

>> great for certain use cases and hopefully more tunes to that CPU

>> implementation.

>>

>> > From the naive openssl benchmarks I did few years back, there was very small difference between mtune/mcpu/just-march, but still for projects where I have separate package feeds for each device (e.g. LG TVs) I prefer to use -mcpu (because I really know that such packages won't ever be used on device with different CPU) and e.g. in LuneOS we're more concerned about package feed size and build time, so we select more generic DEFAULTTUNE which is shared across many MACHINEs and that doesn't have any -mcpu (nor -mtune) options in it, so should be fine as well.

>>

>> Exactly, the point here, we will be best served if we make it one way

>> or other, e.g. raspbian used thumb1 ISA across all rpi implementations

>> and they can use same feeds across all RPis that have even existed. It

>> has advantages of

>> its own to be able to do that, especially for people who work on

>> higher stacks they would be happy with such a setup.

>>

>> So I have to suggest on of three approached

>>

>> 1. Change -mcpu to -mtune and keep everything same. This make feed

>> arches point to tuned packages but fundamentally same for base

>> architecture ( e.g. armv7-a),

>> 2. Just use -mcpu and do not use -march/-mtune and may be provide

>> mechanism to override -mcpu, which is done by packages anyway ( maps

>> directly to package architectures )

>> 3. Just use -march and drop -mcpu and -mtune - Rename feed arches to

>> map to arch+features conventions instead of being CPU specific, this

>> will freak the users since it will be overwhelming to understand the

>> combinations

>>     e.g.  armv7ve+neon+vfpv4 etc. so the combination becomes

>> equivalent to -mcpu, current tune architecture we can construct this

>> easily by appending to march based on TUNE_FEATURES but I think

>> package arches will be a              massive to deal with and users

>> might ask what is this long -march/-mtune pointing to in terms of CPU,

>> but it will address Mark's usecase and will bring us closer to using

>> mcpu usecase, We can probaly do a bettter error reporting

>>     as well for conflicting tune features.

>>

>> I can cook up patches for option 3 from tunes part, packaging part I

>> am not sure maybe we can live with what we have

>> option 2 I already have posted a patch, option 1 would be a simplest

>> patch of all which can be done quickly as well.

>>

>> >

>> > We can easily extend the tune-test script I've used back then when switching to -mcpu to not only use bitbake -e, but also call gcc-cross to check for possible warnings from incompatible march/mcpu combinations and fix those. The old version is here:

>> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test

>> > it was used in mcpu switch here:

>> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test

>> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3

>> >

>> > From the gcc git log I don't see many changes in:

>> > https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/driver-arm.c

>> > nor

>> > https://github.com/gcc-mirror/gcc/commits/master/gcc/config/arm/arm-cpus.in

>> > so I'm really interested which combination issues the warning now.

>> >

>> > Regards,

>> >

>> > On Sat, Jan 26, 2019 at 5:29 PM Khem Raj <raj.khem@gmail.com> wrote:

>> >>

>> >>

>> >> On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle <mark.hatle@windriver.com> wrote:

>> >> >

>> >> > On 1/24/19 9:22 PM, Khem Raj wrote:

>> >> > > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>> >> > >>

>> >> > >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj <raj.khem@gmail.com> wrote:

>> >> > >>>

>> >> > >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <armccurdy@gmail.com> wrote:

>> >> > >>>>

>> >> > >>>> On Wed, Jan 23, 2019 at 12:05 PM Khem Raj <raj.khem@gmail.com> wrote:

>> >> > >>>>>

>> >> > >>>>> tune files which inherit the arch definitions already define appropriate

>> >> > >>>>> -mcpu option, which is equivalent of right -march and -mtune combination

>> >> > >>>>

>> >> > >>>> And what about machines which inherit an arch definition instead of a

>> >> > >>>> cpu definition? Is that no longer supported?

>> >> > >>>

>> >> > >>> I could not find such a machine configuration in several BSP layers I looked at.

>> >> > >>> Do you know of machine definitions where these files are included

>> >> > >>> directly in machine configs ?

>> >> > >>

>> >> > >> Using a CPU specific include but then leaving the generic DEFAULTTUNE

>> >> > >> (ie not enabling any CPU specific TUNE_CCARGS) is equivalent, and I

>> >> > >> guess quite common.

>> >> > >

>> >> > > defaulttune does not play much part in appending -mcpu option to

>> >> > > compiler flags, A case

>> >> > > where this could bypass the setting mcpu is when we do not include a

>> >> > > tune-* for arm based machine

>> >> > > and thats the case I was interested to know.

>> >> > >

>> >> > > again if there is such a BSP I would be interested to test it out.

>> >> > >>

>> >> > >>> if so, then we have to either use _remove or introduce a weak variable

>> >> > >>> to set march only if

>> >> > >>> mcpu is not set which

>> >> > >>

>> >> > >> I think the solution is to ensure that the CPU specific tuning options

>> >> > >> are always compatible with any architecture specific options which may

>> >> > >> be active.

>> >> > >>

>> >> > >> In general our CPU specific tuning files are a little sloppy (e.g.

>> >> > >> defaulting to combinations of VFP versions and architecture levels

>> >> > >> which never exist in the real world). If newer versions of gcc are

>> >> > >> making those issues more apparent then why not take the opportunity to

>> >> > >> fix them properly?

>> >> > >

>> >> > > the mcpu option is helping with right march/mtune combination. while we can

>> >> > > use specific -march=arch(+-)features syntax and combine with right

>> >> > > -mtune to match -mcpu I think we should use

>> >> > > compiler defaults and not try to recreate something that -mcpu would

>> >> > > do it easily for us.

>> >> > >

>> >> > > So either we drop the idea of setting mcpu and use basic -march value

>> >> > > combined with -mtune ( which btw. was default in past)

>> >> > > or if we want to let compiler use ISA for a particular arch

>> >> > > implementation ( cortexXXX ) then we should just use -mcpu and drop

>> >> > > using -mtune and -march.

>> >> > >

>> >> > > I would include towards option 1.

>> >> >

>> >> > I know this is a bit of a 'me too' response, but we have to pick one format and

>> >> > stay with it.  Either option, but not both.

>> >>

>> >> I concur.

>> >>

>> >>

>> >> >

>> >> > -IF- we know that the appropriate -mcpu options are available for all of the

>> >> > potential combinations out there, then this is by far the preferred method in my

>> >> > mind.  Much easier to handle and manage...

>> >>

>> >> -mcpu options are available for known CPU implementations. But there always will

>> >> be weird ones, given how people can pick and choose subsystems for SOC on this

>> >> architecture, and its highly probable that they wont be in gcc. so real question we need to answer for is, should we design for those cases and how often does this often.

>> >>

>> >>

>> >> >

>> >> > However, the more complex route came out as various 'odd-ball' (and people claim

>> >> > don't exist, but they do) custom ARM cores get released without 'mandatory' math

>> >> > units, or some other odd ball variation.  (I've seen this numerous times over

>> >> > the last 20 years that something that doesn't exist, does... all because it's a

>> >> > custom part.)

>> >>

>> >> Yes, I am dealing with one such design even today

>> >>

>> >>

>> >> >

>> >> > If we have an easy way to define the -mcpu= means some magic combination of

>> >> > -march/-mtune within the GCC spec itself, then I'm 100% for moving to -mcpu to

>> >> > rid ourselves of this mess.. and then we still have the flexibility to easily

>> >> > update/add tunes and GCC configuration for the odd-balls that seem to crop up

>> >> > regularly.

>> >>

>> >> So yes we can do nearly same but not exactly same. We have to start adding or deleting

>> >> features via -march and -mtune would be same value, but there are cases where gcc defines

>> >> internal properties based on mcpu, that is not representable in those suffixes we will add. so

>> >> we will come very close but not exact and I think compiler is right in this case because we

>> >> are not exactly telling it about a CPU implementation, but we are telling the cpu has these properties, so it really may not be one of standard cpu implementation.

>> >>

>> >>

>> >> >

>> >> > (I know -I- can always patch GCC for new -mcpu combinations, but I'm not

>> >> > thinking about 'me', I'm thinking about the user of OE who is told 'use this

>> >> > CPU, it has this set of functions' and is NOT a compiler expert who can wade

>> >> > through GCC spec files and generate patches with any confidence.)

>> >> >

>> >>

>> >> I would think we can solve this for these niche cases, via using -march/-mtune and drop

>> >> -mcpu, we can append adding/deleting a given feature e.g. neon or vfp or vfpv3 etc.

>> >> but this would mean we have to rename our package feed names as well to match this

>> >> new representation, which currently is mapped to mcpu values. This is quite a departure

>> >> from package feeds point of view. but its more aligned with how we have defined arch and tunes.

>> >> so pick the battles.

>> >>

>> >>

>> >> > --Mark

>> >> >

>> >> > >>

>> >> > >>>>> and is preferred since gcc is getting stricter and stricter with option

>> >> > >>>>> check semantics and can now find incompatible -march and -mcpu options

>> >> > >>>>> better with every release. It does internal feature consistency check

>> >> > >>>>> and if it finds out discrepency between what -mcpu would expand to as

>> >> > >>>>> compared to -march it will flag the options to be incompatible, for

>> >> > >>>>> naked eye it sounds wrong but gcc would translate -mcpu to a given

>> >> > >>>>> -march internally and it might not match to what we set in these arch

>> >> > >>>>> files.

>> >> > >>>>>

>> >> > >>>>> The effects are quite subtle, where this can result in configure test

>> >> > >>>>> failing to compile due to these incompatible options and a feature

>> >> > >>>>> option getting disabled for a recipe for no reason.

>> >> > >>>>>

>> >> > >>>>> e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and

>> >> > >>>>> -march=armv7-a are incompatible, many features in libstdc++ ends up

>> >> > >>>>> disabled due to configure check failures e.g. size_t size, ptrdiff_t

>> >> > >>>>> sizes, which inturn results in compiling libstdc++ with unwanted

>> >> > >>>>> disabled features.

>> >> > >>>>

>> >> > >>>> It would be interesting to see more specific details of this.

>> >> > >>>

>> >> > >>> These are configure tests which fail when -Werror is in use and is not

>> >> > >>> limited to libstdc++

>> >> > >>> it can happen in any package. Since the diagnostic about incompatible

>> >> > >>> march mcpu pair

>> >> > >>> is a warning in general, it does not matter, but when we have -Werror

>> >> > >>> enabled this turns

>> >> > >>> into error, You can simply try a small helloworld example to see the effects.

>> >> > >>>

>> >> > >>>>

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

>> >> > >>>>> ---

>> >> > >>>>>  meta/conf/machine/include/arm/arch-armv4.inc   | 1 -

>> >> > >>>>>  meta/conf/machine/include/arm/arch-armv5.inc   | 1 -

>> >> > >>>>>  meta/conf/machine/include/arm/arch-armv6.inc   | 1 -

>> >> > >>>>>  meta/conf/machine/include/arm/arch-armv7a.inc  | 1 -

>> >> > >>>>>  meta/conf/machine/include/arm/arch-armv7ve.inc | 1 -

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

>> >> > >>>>>  6 files changed, 1 insertion(+), 6 deletions(-)

>> >> > >>>>>

>> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc

>> >> > >>>>> index 47a7ad2830..52d8ab1e8f 100644

>> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv4.inc

>> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv4.inc

>> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv4"

>> >> > >>>>>

>> >> > >>>>>  TUNEVALID[arm] = "Enable ARM instruction set"

>> >> > >>>>>  TUNEVALID[armv4] = "Enable instructions for ARMv4"

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

>> >> > >>>>>  # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb

>> >> > >>>>>  # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does

>> >> > >>>>>  # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

>> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc

>> >> > >>>>> index f9068af9de..1fe1b6b8e4 100644

>> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv5.inc

>> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc

>> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv5"

>> >> > >>>>>

>> >> > >>>>>  TUNEVALID[armv5] = "Enable instructions for ARMv5"

>> >> > >>>>>  TUNECONFLICTS[armv5] = "armv4"

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

>> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"

>> >> > >>>>>

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

>> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc

>> >> > >>>>> index 6c838e999c..adb9be8050 100644

>> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv6.inc

>> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv6.inc

>> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv6hf"

>> >> > >>>>>

>> >> > >>>>>  TUNEVALID[armv6] = "Enable instructions for ARMv6"

>> >> > >>>>>  TUNECONFLICTS[armv6] = "armv4 armv5"

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

>> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"

>> >> > >>>>>

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

>> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc

>> >> > >>>>> index a2663d8008..09d2c03a5d 100644

>> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7a.inc

>> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc

>> >> > >>>>> @@ -3,7 +3,6 @@ ARM_INSTRUCTION_SET ?= "thumb"

>> >> > >>>>>

>> >> > >>>>>  TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"

>> >> > >>>>>  TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

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

>> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"

>> >> > >>>>>

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

>> >> > >>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc

>> >> > >>>>> index 4d9260fecb..31e334f645 100644

>> >> > >>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc

>> >> > >>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc

>> >> > >>>>> @@ -2,7 +2,6 @@ DEFAULTTUNE ?= "armv7vethf"

>> >> > >>>>>

>> >> > >>>>>  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"

>> >> > >>>>>  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"

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

>> >> > >>>>>  MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"

>> >> > >>>>>

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

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

>> >> > >>>>> index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"

>> >> > >>>>>

>> >> > >>>>>  AVAILTUNES += "iwmmxt"

>> >> > >>>>>  ARMPKGARCH_tune-iwmmxt = "iwmmxt"

>> >> > >>>>> --

>> >> > >>>>> 2.20.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

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

Patch

diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..52d8ab1e8f 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,6 @@  DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' -march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..1fe1b6b8e4 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,6 @@  DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv5', 'armv5:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv4.inc
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
index 6c838e999c..adb9be8050 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -2,7 +2,6 @@  DEFAULTTUNE ?= "armv6hf"
 
 TUNEVALID[armv6] = "Enable instructions for ARMv6"
 TUNECONFLICTS[armv6] = "armv4 armv5"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' -march=armv6', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv6', 'armv6:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
index a2663d8008..09d2c03a5d 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -3,7 +3,6 @@  ARM_INSTRUCTION_SET ?= "thumb"
 
 TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
 TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', ' -march=armv7-a', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', 'armv7a:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv6.inc
diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc
index 4d9260fecb..31e334f645 100644
--- a/meta/conf/machine/include/arm/arch-armv7ve.inc
+++ b/meta/conf/machine/include/arm/arch-armv7ve.inc
@@ -2,7 +2,6 @@  DEFAULTTUNE ?= "armv7vethf"
 
 TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"
 TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', ' -march=armv7ve', '', d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"
 
 require conf/machine/include/arm/arch-armv7a.inc
diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
index f27423cb2e..6e577697cc 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', ' -mcpu=iwmmxt', '', d)}"
 
 AVAILTUNES += "iwmmxt"
 ARMPKGARCH_tune-iwmmxt = "iwmmxt"