public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Julian Brown <julian@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, paul@codesourcery.com,
	Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>
Subject: Re: [PATCH, ARM] Fix ABI for double-precision helpers on	single-float-only CPUs
Date: Thu, 02 Jun 2011 15:35:00 -0000	[thread overview]
Message-ID: <1307028902.17090.6.camel@e102346-lin.cambridge.arm.com> (raw)
In-Reply-To: <20110527173238.630c95b8@rex.config>


On Fri, 2011-05-27 at 17:32 +0100, Julian Brown wrote:
> The helper functions used to implement double-precision arithmetic on
> ARM processors that only support single-precision arithmetic in hardware
> should use the soft-float ABI (i.e. passing and returning floating-point
> arguments in core registers), even when -mfloat-abi=hard is in effect.
> This patch tweaks the ABI for the affected functions so that is true.
> 
> Tested with cross to ARM EABI, and by manually observing compiler
> output. We've also been carrying this patch in our local tree for some
> time without issue.
> 
> OK to apply?
> 
> Thanks,
> 
> Julian
> 
> ChangeLog
> 
>     gcc/
>     * config/arm/arm.c (arm_libcall_uses_aapcs_base)
>     (arm_init_cumulative_args): Use correct ABI for double-precision
>     helper functions in hard-float mode if only single-precision
>     arithmetic is supported in hardware.

I see Paul has already approved this, but I've just spotted one
potential problem that might cause latent bugs sometime in the future.

The code to register the libcalls is only run once, the first time we
try to look up a libcall.  If we ever end up allowing dynamic changing
of CPU and optimization options, not registering the other libcalls will
lead to subtle problems at run time.  I suggest that these functions be
unconditionally added along with the other libcalls.

I also don't understand why all the tests are needed in
arm_init_cumulative_args?  Surely arm_libcall_uses_aapcs_base() will
already have run that test.

R.



  parent reply	other threads:[~2011-06-02 15:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27 17:50 Julian Brown
2011-06-02 13:17 ` Paul Brook
2011-06-02 15:35 ` Richard Earnshaw [this message]
2011-06-03 17:41   ` Julian Brown
2011-06-06 16:07     ` Richard Earnshaw
2011-06-14  4:09     ` Ramana Radhakrishnan

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=1307028902.17090.6.camel@e102346-lin.cambridge.arm.com \
    --to=rearnsha@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=julian@codesourcery.com \
    --cc=paul@codesourcery.com \
    --cc=ramana.radhakrishnan@linaro.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).