From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13958 invoked by alias); 2 Dec 2014 14:01:34 -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 13937 invoked by uid 89); 2 Dec 2014 14:01:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Dec 2014 14:01:31 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Tue, 02 Dec 2014 14:01:29 +0000 Received: from [10.1.207.43] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2014 14:01:27 +0000 Message-ID: <547DC637.5060906@arm.com> Date: Tue, 02 Dec 2014 14:01:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: James Greenhalgh , Andrew Stubbs CC: Richard Earnshaw , "gcc-patches@gcc.gnu.org" Subject: Re: [arm][patch] fix arm_neon_ok check on !arm_arch7 References: <5414B99D.3020202@codesourcery.com> <5416B580.9070208@arm.com> <5416C5C3.8070603@codesourcery.com> <20140923082716.GA28745@arm.com> In-Reply-To: <20140923082716.GA28745@arm.com> X-MC-Unique: 114120214012900501 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00163.txt.bz2 On 23/09/14 09:27, James Greenhalgh wrote: > On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote: >> On 15/09/14 10:46, Richard Earnshaw wrote: >>> Hmm, I wonder if arm_override_options should reject neon + (arch < 7). >> Is this more to your taste? > Is this really such a good idea? It causes carnage throughout the > testsuite if you have configured with support for Neon and the testcase > is written with dg-options for a pre-armv7-a -march value. > > For example in: > testsuite/gcc.target/arm/di-longlong64-sync-withhelpers.c > > Which forces -march=3Darmv5. > > Perhaps you just have to fix the effective-target-ok tests - but then > we lose swathes of test coverage. This also causes subtle Linux kernel compile failures. Over there they use make rules where they check if the compiler supports=20 -march=3Darmv5te and if not use -march=3Darmv4t. With this patch if the compiler is configured with something like=20 --with-fpu=3Dneon the test will fail with your error message, even though the compiler supports -march=3Darmv5te. Kyrill > > Thanks, > James > >> Andrew >> >> P.S. arm_override_options was renamed in 2010. >> 2014-09-15 Andrew Stubbs >> >> * gcc/config/arm/arm.c (arm_option_override): Reject -mfpu=3Dneon >> when architecture is older than ARMv7. >> >> Index: gcc/config/arm/arm.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- gcc/config/arm/arm.c (revision 215228) >> +++ gcc/config/arm/arm.c (working copy) >> @@ -2845,6 +2845,9 @@ >>=20=20=20 >> arm_fpu_desc =3D &all_fpus[arm_fpu_index]; >>=20=20=20 >> + if (TARGET_NEON && !arm_arch7) >> + error ("target CPU does not support NEON"); >> + >> switch (arm_fpu_desc->model) >> { >> case ARM_FP_MODEL_VFP: