On Fri, Jun 16, 2017 at 10:11 PM, Richard Earnshaw <richard.earns...@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.
