On 13 June 2017 at 19:35, Richard Earnshaw (lists) <richard.earns...@arm.com> 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. >
Hi Richard, Thanks for the quick iteration, and sorry for responding here ;-) The validation results of the whole roll-up patch look much better: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/248942-roll-up.patch/report-build-info.html (you can ignore the "better" in the arm-none-linux-gnueabihf table, it's noise in the results). The other 2 better are actually 100 "pass" becoming 26 "unsupported" because arm_fp_ok now returns false in the corresponding configs (there's no fpu for the selected processor/arch) As of the regression --with-cpu=cortex-m3, the thumb2-slow-flash-data-[2345].c tests may need an update: they are compiled with -march=armv7e-m -mfloat-abi=hard -O2 -mthumb -mslow-flash-data resulting in: cc1: error: -mfloat-abi=hard: selected processor lacks an FPU Christophe > R.
