From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16660 invoked by alias); 3 Dec 2014 15:03:50 -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 16643 invoked by uid 89); 3 Dec 2014 15:03:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Dec 2014 15:03:43 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XwBSt-0004JW-S0 from Andrew_Stubbs@mentor.com ; Wed, 03 Dec 2014 07:03:40 -0800 Received: from [172.30.4.32] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Wed, 3 Dec 2014 15:03:38 +0000 Message-ID: <547F2646.7020308@mentor.com> Date: Wed, 03 Dec 2014 15:03:00 -0000 From: Andrew Stubbs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: , Kyrill Tkachov CC: James Greenhalgh , Andrew Stubbs , 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> <547DC637.5060906@arm.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00285.txt.bz2 On 02/12/14 21:45, Ramana Radhakrishnan wrote: > I've spent some time this evening pondering over your patch. Firstly > it appears that the current behaviour is going to cause more breakage > than originally expected. If this is to go in we'd have a number of > users having to add -mfloat-abi=soft to the command line option to > ensure that -march=armv5te works just fine on the files where > march=armv5te in the first places. Agreed. I've just reverted the patch. > I'm not sure that the original patch is enough. > > The tools have always allowed us to drop down the arch to > march=armv5te along with using -mfpu=neon. We are now changing command > line behaviour, so an inform in terms of diagnostics to the user would > be useful as it states that we don't really have mfpu=neon generating > neon code any more because of this particular case. If we are to do > this then the original patch is probably not enough as it then doesn't > handle the case of TARGET_VFP3 / TARGET_VFP5 / TARGET_NEON_FP16 / > TARGET_FP16 / TARGET_FPU_ARMV8 etc. etc. etc. I'll take a look at those shortly. Andrew