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

[Khem Raj]

On Thu, Jun 7, 2018 at 12:14 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Wed, Jun 6, 2018 at 10:58 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> On 6/6/18 4:42 PM, Andre McCurdy wrote:
>>> On Wed, Jun 6, 2018 at 3:43 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>
>>> The -mcpu, -march and -mtune options are not new and gcc 6 and 7 catch
>>> the same conflicts. It doesn't make sense that gcc8 is just catching
>>> more issues.
>>
>> It does make sense. the option parsing for these specific options on arm
>> have been revamped after gcc7, see
>>
>> https://github.com/kraj/gcc/compare/a99ae290af49793cd3db7a74f3dbc59e64d356a1...68b54adbd7b10c66d968d74b96fba552bd46ebb7
>
> Thanks. These commits seem to be related to handling of options like
> "-mcpu=cortexa9+nosimd". Was that the error you saw in testing?
>
> If you can provide the command line that caused the error then it
> should be quick to establish whether it's gcc8 being more picky.
>
> Or perhaps there's always been a warning and -Werror has been added to
> a gcc8 Makefile where it wasn't before?
>
>>> If we are trying to build something which is reusable across multiple
>>> machines with the same architecture then it's a bug to be passing
>>> machine specific CFLAGS. Making the machine specific CFLAGS more
>>> generic is not the right solution.
>>
>> being reusable is a side-effect and a good one. Real problem is we are not
>> matching to what we say in package arches, Probably you are confusing tunes
>> to be meant for static code generation for a given CPU.
>
> Sorry, I don't really follow what you mean?
>
>> I am interested to
>> hear more ideas to what would be right solution if this is not it.
>
> I'd like to understand what the problem is first before trying to
> propose any solutions.
>
> ie what specifically has changed with gcc8 to cause the error which
> wasn't seen before?


I would suggest take this gcc8 patch series and revert this one then build
gcc-runtime for rpi3

>
>>> Anyway, I suspect the real issue here is that when we build gcc to run
>>> on the target we currently configure using "--with-arch=armv7-a" for
>>> both armv7a and armv7ve. It was done that way deliberately to try to
>>> avoid rebuilds when switching between armv7a and armv7ve machines,
>>> although thinking about that now I'm not sure it makes so much sense.
>>> Does your original problem go away if you simply change:
>>>
>>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"
>>>
>>> to
>>>
>>>    EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve"
>>>
>>> in gcc-target.inc ?
>>
>> No, this is not the problem I am talking about gcc-runtime which is
>> configured during cross build but built for target later on.
>
> OK, good to rule that out. It's nothing to do with gcc8 and I've sent
> a separate patch to fix it.