This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options
On Fri, Jun 16, 2017 at 10:11 PM, Richard Earnshaw
> 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.
> 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.
This is definitely a user visible change and it would be great to put
this into the release notes for GCC 8.
> "Let the mayhem begin..."