gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Andre McCurdy]

This change looks wrong (or at least incomplete and lacking a decent
explanation):

  http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=fbec01f01fdad23d95271db063ee0a4d0ab44568

It was never posted to the list but seems to have made it as far as master-next.

Re: gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Khem Raj]

On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> This change looks wrong (or at least incomplete and lacking a decent
> explanation):

why do you think it is wrong ? I would be happy to make the
explanation more decent
if you have ideas please share.

>
>   http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
>
> It was never posted to the list but seems to have made it as far as master-next.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Richard Purdie]

On Tue, 2018-05-29 at 12:13 -0700, Khem Raj wrote:
> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > 
> > This change looks wrong (or at least incomplete and lacking a
> > decent
> > explanation):
> why do you think it is wrong ? I would be happy to make the
> explanation more decent
> if you have ideas please share.
> 
> > 
> > 
> >   http://git.openembedded.org/openembedded-core/commit/?h=master-ne
> > xt&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
> > 
> > It was never posted to the list but seems to have made it as far as
> > master-next.

I don't know where Ross got the patches from but I've taken over and he
told me the patches in mut were ready. I didn't take this one however.

My concern is the use of "remove" which I really prefer not to use in
OE-Core. In core, its a sign that we have the overall structure wrong
as we should never need to do this.

I'd like to understand why gcc-runtime needs this special treatment and
whether there are other arm tunes which have the same issue? Should we
be tweaking the main tune files in some way instead?

Cheers,

Richard

Re: gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Andre McCurdy]

On Tue, May 29, 2018 at 12:13 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> This change looks wrong (or at least incomplete and lacking a decent
>> explanation):
>
> why do you think it is wrong ? I would be happy to make the
> explanation more decent
> if you have ideas please share.

I would be happy to try... if I had any idea why you think you need it!

What causes the conflict in flags and why hasn't it been seen before?
Why do you only need to fix Cortex A7 and not when building for other
armv7ve cores?

>>
>>   http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
>>
>> It was never posted to the list but seems to have made it as far as master-next.
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Khem Raj]

On Tue, May 29, 2018 at 1:12 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2018-05-29 at 12:13 -0700, Khem Raj wrote:
>> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy@gmail.com>
>> wrote:
>> >
>> > This change looks wrong (or at least incomplete and lacking a
>> > decent
>> > explanation):
>> why do you think it is wrong ? I would be happy to make the
>> explanation more decent
>> if you have ideas please share.
>>
>> >
>> >
>> >   http://git.openembedded.org/openembedded-core/commit/?h=master-ne
>> > xt&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
>> >
>> > It was never posted to the list but seems to have made it as far as
>> > master-next.
>
> I don't know where Ross got the patches from but I've taken over and he
> told me the patches in mut were ready. I didn't take this one however.

Thats right. since Ross has been testing gcc8 patchset
and reducing the number of patches needed for enabling gcc8 and this one seems
more benign, to go in independent of rest of gcc8 patches.

>
> My concern is the use of "remove" which I really prefer not to use in
> OE-Core. In core, its a sign that we have the overall structure wrong
> as we should never need to do this.

Yes and its a valid one. A better way would be to not use -mcpu for
recipes which
are not compiled for machine specifically, our tunes however are using
this extensively
and changing that probably should not be clubbed together with gcc
upgrade. the warning
emitted with gcc8 is just highlighting the problem that has been
latent. -mcpu is not
consistent across different architecture, x86 has removed it for arm
it means sum of
march+mtune etc.

on arm mcpu backfills either of march or mtune if not supplied on
cmdline, and in case
there are conflicts the rightmost setting wins, however this
precedence can then conflict
with builtin defaults, thats what we are seeing here.

I thought about proposing a separate series for removing -mtunes
atleast for arm. However such a change would
need very careful testing, since this can have runtime performance
impacts and other
optimization bugs etc. So regardless we should do it where we only use
-march and -mtune
combination which will let it target more broader spectrum of cpus and
users will be able
to generate pre-compiled binaries for larger base ISA so there are a
few advantages

leaving compiler do its job always results in best performing code in
my experience, adding
too many fine-tuning at global level are overkill anyway. apps ask for
specific opt flags themselves where needed, and if we have empirical
data where it proves helpful we can always do that at recipe level via
cflags.

>
> I'd like to understand why gcc-runtime needs this special treatment and
> whether there are other arm tunes which have the same issue? Should we
> be tweaking the main tune files in some way instead?
>

Yes we should be re-looking at how arm tune flles stagger various
compiler options
especially march/mtune/mcpu, but I would think that is a separate topic.

> Cheers,
>
> Richard
>
>

Re: gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Khem Raj]

On Tue, May 29, 2018 at 1:34 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Tue, May 29, 2018 at 12:13 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> This change looks wrong (or at least incomplete and lacking a decent
>>> explanation):
>>
>> why do you think it is wrong ? I would be happy to make the
>> explanation more decent
>> if you have ideas please share.
>
> I would be happy to try... if I had any idea why you think you need it!
>
> What causes the conflict in flags and why hasn't it been seen before?
> Why do you only need to fix Cortex A7 and not when building for other
> armv7ve cores?
>

gcc-runtime is a bit special where it gets itself configured when
building cross compiler
but then we tame it to re-target itself for target using some shims
e.g. setting generic
arch values so it can plug itself amicably when we build gcc for
target and use it ondevice
because it needs to rely on right combination of options, and gcc for
target is also made
to target more common ISAs via doing things like below.

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

these options cause additional march values to be added.

If you are interested. Plug this patch out and use gcc8 patches I have
floating around
and you can see whats going on.

I am also interested in finding a solution where we do not need this patch.

>>>
>>>   http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=fbec01f01fdad23d95271db063ee0a4d0ab44568
>>>
>>> It was never posted to the list but seems to have made it as far as master-next.
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core