Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Fri, Jun 16, 2017 at 10:11 PM, Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
> On 13/06/17 18:35, Richard Earnshaw (lists) wrote:
>> On 09/06/17 13:53, Richard Earnshaw wrote:
>>>
>>> During the ARM BoF at the Cauldron last year I mentioned that I wanted
>>> to rework the way GCC on ARM handles the command line options.  The
>>> problem was that most users, and even many experts, can't remember
>>> which FPU/SIMD unit comes with which CPU and that consequently many
>>> users were inadvertenly generating sub-optimal code for their system.
>>>
>>> This patch series implements the proposed change and provides support
>>> for a generic way of adding optional features to architectures and CPU
>>> names.  The documentation patches at the end of the series explain the
>>> new syntax, so I won't repeat all that here.  Suffice to say here that
>>> the result is that the -mfpu option now defaults to 'auto', which
>>> allows the compiler to infer the floating-point and simd options from
>>> the CPU/architecture options and that these options can normally be
>>> expressed in a context-specific manner like +simd or +fp without
>>> having to know precisely which variant is implemented.  Long term I'd
>>> like to deprecate -mfpu and entirely move over to the new syntax; but
>>> it's too early to start that process now.
>>>
>>> All the patches in the series should build a working basic compiler,
>>> but the multilib selection will not work correctly until the relevant
>>> patches towards the end are applied.  It is not really feasible to
>>> retain that functionality without collapsing too many of the patches
>>> together into one hunk.  It's also possible that some tests in the
>>> testsuite may exhibit transient misbehaviour, but there should be no
>>> regressions by the end of the sequence (some tests no-longer run in
>>> the default configurations because the default CPU does not have
>>> floating-point support).
>>>
>>> Just two patches are to the generic code, but both are fairly trivial.
>>> One permits the sbitmap code to be used in the driver programs and the
>>> other provides a way of escaping the meta-character in some multilib
>>> reuse strings.
>>>
>>> I won't apply any of this series until those two patches have been
>>> approved, and I won't commit anything before the middle of next week
>>> even then.  This is a fairly complex change and it deserves some time
>>> for people to comment before committing.
>>>
>>
>> The attached is a roll-up of the entire series after the updates I've
>> posted today.  This should eliminate any potential issues with applying
>> the series for the purposes of testing.  Please don't post issues in
>> reply to this, but to the individual patches in the series.
>>
>> R.
>>
>
> This series has now been committed after rebasing on to the latest
> trunk.  Nothing material has changed so I'm not reposting the patches again.
>

Yay !

This is definitely a user visible change and it would be great to put
this into the release notes for GCC 8.

Ramana

> "Let the mayhem begin..."
>
> R.