[OE-core] [PATCH V2] arch-arm: Do not add -march options for arm architecture along with -mcpu

Khem Raj raj.khem at gmail.com
Fri Jan 25 03:37:29 UTC 2019


On Thu, Jan 24, 2019 at 11:37 AM Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>
> On Wed, 2019-01-23 at 16:18 -0800, Khem Raj wrote:
> > 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.
> >
> > If user has machine definitions which do not inherit the arm tune
> > files
> > then they can still use the -march switch as such
> >
> > Signed-off-by: Khem Raj <raj.khem at gmail.com>
> > ---
> > v2: Only delete -march if -mcpu is set
>
> I suspect this might cause:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/212

Yes, this is because valgrind is trying to undo the effects of
specifying mcpu + march together,
I have send a patch to fix it. see
https://patchwork.openembedded.org/patch/158223/

>
> Cheers,
>
> Richard
>


More information about the Openembedded-core mailing list