From patchwork Mon Jul 26 05:01:03 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chung-Lin Tang X-Patchwork-Id: 59890 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 04838B6F04 for ; Mon, 26 Jul 2010 15:01:25 +1000 (EST) Received: (qmail 13974 invoked by alias); 26 Jul 2010 05:01:22 -0000 Received: (qmail 13521 invoked by uid 22791); 26 Jul 2010 05:01:20 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Jul 2010 05:01:13 +0000 Received: (qmail 10851 invoked from network); 26 Jul 2010 05:01:11 -0000 Received: from unknown (HELO ?211.74.234.20?) (cltang@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jul 2010 05:01:11 -0000 Message-ID: <4C4D168F.3080708@codesourcery.com> Date: Mon, 26 Jul 2010 13:01:03 +0800 From: Chung-Lin Tang User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Earnshaw CC: gcc-patches Subject: Re: [PATCH, ARM] soft/hard-float preprocessor symbol References: <4C471AF4.4000302@codesourcery.com> <1279921608.2191.14.camel@rwe-pc> In-Reply-To: <1279921608.2191.14.camel@rwe-pc> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Richard Earnshaw wrote: > The tests should be on arm_pcs_default. If that has the value > ARM_PCS_AAPCS_VFP then __ARM_PCS_VFP should be defined. If it has the > value ARM_PCS_AAPCS, then __ARM_PCS should be defined. In other cases, > I think neither should be defined (leaving the option open to create new > pre-processor defines in future). > > That does leave nothing defined for the IWMMXT variant. I'm not > entirely sure what to do about that. It appears that this just follows > the base standard for calling, in which case __ARM_PCS probably should > be defined, but I want to think that case through further before making > that decision: there may be a subtlety that I've missed. > > R. Hi Richard, I have update the patch as you have suggested. Please see if this is okay. Thanks, Chung-Lin Index: arm.c =================================================================== --- arm.c (revision 162525) +++ arm.c (working copy) @@ -711,7 +711,7 @@ the next function. */ static int after_arm_reorg = 0; -static enum arm_pcs arm_pcs_default; +enum arm_pcs arm_pcs_default; /* For an explanation of these variables, see final_prescan_insn below. */ int arm_ccfsm_state; Index: arm.h =================================================================== --- arm.h (revision 162525) +++ arm.h (working copy) @@ -94,7 +94,13 @@ if (arm_arch_iwmmxt) \ builtin_define ("__IWMMXT__"); \ if (TARGET_AAPCS_BASED) \ - builtin_define ("__ARM_EABI__"); \ + { \ + if (arm_pcs_default == ARM_PCS_AAPCS_VFP) \ + builtin_define ("__ARM_PCS_VFP"); \ + else if (arm_pcs_default == ARM_PCS_AAPCS) \ + builtin_define ("__ARM_PCS"); \ + builtin_define ("__ARM_EABI__"); \ + } \ } while (0) /* The various ARM cores. */ @@ -1641,6 +1647,9 @@ ARM_PCS_UNKNOWN }; +/* Default procedure calling standard of current compilation unit. */ +extern enum arm_pcs arm_pcs_default; + /* A C type for declaring a variable that is used as the first argument of `FUNCTION_ARG' and other related values. */ typedef struct