public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Chung-Lin Tang <cltang@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, ARM] soft/hard-float preprocessor symbol
Date: Fri, 23 Jul 2010 21:47:00 -0000	[thread overview]
Message-ID: <1279921608.2191.14.camel@rwe-pc> (raw)
In-Reply-To: <4C471AF4.4000302@codesourcery.com>

On Thu, 2010-07-22 at 00:06 +0800, Chung-Lin Tang wrote:
> Hi, this patch adds built-in preprocessor symbols __ARM_PCS, 
> __ARM_PCS_VFP to indicate the current soft/hard-float calling 
> convention, as described in the draft ACLE.
> 
> If approved, please help to apply to trunk, as I don't have commit 
> rights yet.
> 
> Thanks,
> Chung-Lin
> 
> 2010-07-22  Chung-Lin Tang  <cltang@codesourcery.com>
> 
> 	* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Define __ARM_PCS or
> 	__ARM_PCS_VFP to indicate soft/hard-float calling convention.
> 
> 
> 
> plain text document attachment (pcs.diff)
> Index: arm.h
> ===================================================================
> --- arm.h	(revision 162381)
> +++ arm.h	(working copy)
> @@ -94,7 +94,13 @@
>  	if (arm_arch_iwmmxt)				\
>  	  builtin_define ("__IWMMXT__");		\
>  	if (TARGET_AAPCS_BASED)				\
> -	  builtin_define ("__ARM_EABI__");		\
> +	  {						\
> +	    if (TARGET_VFP && TARGET_HARD_FLOAT_ABI)	\
> +	      builtin_define ("__ARM_PCS_VFP");		\
> +	    else					\
> +	      builtin_define ("__ARM_PCS");		\
> +	    builtin_define ("__ARM_EABI__");		\
> +	  }						\
>      } while (0)
>  
>  /* The various ARM cores.  */

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.


  parent reply	other threads:[~2010-07-23 21:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 16:06 Chung-Lin Tang
2010-07-22 22:32 ` Mark Mitchell
2010-07-23 21:47 ` Richard Earnshaw [this message]
2010-07-26  5:01   ` Chung-Lin Tang
2010-07-27 16:35     ` Richard Earnshaw
2010-07-28 15:49       ` Chung-Lin Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1279921608.2191.14.camel@rwe-pc \
    --to=rearnsha@arm.com \
    --cc=cltang@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).