From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59554 invoked by alias); 14 Jun 2017 10:21:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59515 invoked by uid 89); 14 Jun 2017 10:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=turnaround, H*c:iso-8859-15 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Jun 2017 10:21:10 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36AE01596; Wed, 14 Jun 2017 03:21:13 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 931973F581; Wed, 14 Jun 2017 03:21:12 -0700 (PDT) Subject: Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options To: Christophe Lyon Cc: "gcc-patches@gcc.gnu.org" References: <22c48b30-d5c4-72f5-a730-67250ab9e566@arm.com> From: "Richard Earnshaw (lists)" Message-ID: <87ce29ed-2d7d-ebad-8b00-d2d926e1cb64@arm.com> Date: Wed, 14 Jun 2017 10:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-06/txt/msg01015.txt.bz2 On 14/06/17 10:08, Christophe Lyon wrote: > On 13 June 2017 at 19: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. >> > > 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 > No problem, that request is aimed at code reviews, not at overall comments on the test results. > (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) That's somewhat expected, and in some ways the 'right thing'. The selected target really doesn't have an FPU so it's correct that the infrastructure deduces this. Of course, we might want to adjust the tests so that they do try harder to enable an FPU, but that can be done later on a case by case basis. > > 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 > Yes, those need updating to -march=armv7e-m+fp. The tests are somewhat bogus in that they are assuming that the internal 'vfp' fpu that was previously configured was 'right' for this architecture. That assumption was bogus and it's this sort of nonsense that this patch set is really trying to address. Many thanks for the quick turn-around on the tests again. It looks like we're nearly there. I'll update patch 32 to add these changes, but won't bother with another roll-up this time. R. > Christophe > > >> R.