From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117301 invoked by alias); 18 May 2015 07:05:35 -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 117261 invoked by uid 89); 18 May 2015 07:05:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mx07-00178001.pphosted.com Received: from mx07-00178001.pphosted.com (HELO mx07-00178001.pphosted.com) (62.209.51.94) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 18 May 2015 07:05:33 +0000 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id t4I6dpAf006124; Mon, 18 May 2015 09:05:29 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 1udnnh26e9-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2015 09:05:29 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8157F38; Mon, 18 May 2015 07:05:26 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas3.st.com [10.75.90.18]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6036828B8; Mon, 18 May 2015 07:05:26 +0000 (GMT) Received: from [164.129.122.197] (164.129.122.197) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 18 May 2015 09:05:26 +0200 Message-ID: <55598F35.1010709@st.com> Date: Mon, 18 May 2015 07:18:00 -0000 From: Christian Bruel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ramana Radhakrishnan CC: "gcc-patches@gcc.gnu.org" , Richard Earnshaw , "nickc@redhat.com" Subject: Re: [PATCH, ARM] attribute target (thumb,arm) [4/6] respin (4th) References: <554A243B.8010902@st.com> <554A9DB1.1070009@codesourcery.com> <554C7459.4000806@arm.com> In-Reply-To: <554C7459.4000806@arm.com> X-No-Archive: yes Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-18_01:2015-05-15,2015-05-17,1970-01-01 signatures=0 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01528.txt.bz2 Hi Ramana, On 05/08/2015 10:31 AM, Ramana Radhakrishnan wrote: > > I'm still playing with the code, so this is a partial review. > > We should prevent inlining of ARM state functions into functions we know > will be T16 if !TARGET_SOFT_FLOAT on the grounds that the architecture > doesn't have floating point instruction encodings in the T16 ISA > (Thumb1). We'll just cause internal compiler errors if we allow this. > I tried to forge a bit with this situation, but I couldn't generate such inconsistencies, as the situation is rejected with a : "sorry, unimplemented: Thumb-1 hard-float VFP ABI" when using -march=armv6 -mthumb -mhard-float (would that match with T16 && !TARGET_SOFT_FLOAT) Do you have the example producing an ICE ? That would be interesting to add it in the testsuite. by the way, I think the error message should be changed from "sorry, unimplemented: Thumb-1 hard-float VFP ABI" to a user error: "Can't use Thumb-1 hard-float VFP ABI" Christian