public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: FX <fxcoudert@gmail.com>
Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
Subject: Re: [patch, Fortran] IEEE support for aarch64-apple-darwin
Date: Wed, 8 Dec 2021 16:08:28 +0000	[thread overview]
Message-ID: <db90b91c-b577-4f51-521d-63ad76d1e255@foss.arm.com> (raw)
In-Reply-To: <D754D2F9-8A7A-4EC0-9FF8-D1694E982ABA@gmail.com>



On 08/12/2021 15:47, FX via Gcc-patches wrote:
> Hi Richard,
> 
>> This isn't a full review, but I do have a question: is this really specific to Darwin?  or is it really generic aarch64 code?  If the former, then the file name is not right and it should reflect the darwin-specific nature of the contents.  If the latter, then I wonder why most other fortran targets don't seem to have specific implementations of this.
> 
> The code is not specific to Darwin, but right now I chose to only enable on Darwin because:
> - All glibc targets are covered already by using glibc <fenv.h> function calls
> - I don’t know if there are other aarch64 targets that exist, support Fortran and IEEE, but don’t have glibc
> 
> I’d suggest other non-glibc aarch64 targets could be added to the support and enable this code, but I don’t want to do it unless it’s been tested there. IEEE support is optional in Fortran, so I suggest we keep it “opt-in”: targets where it’s known to work enable it, but it’s off by default on other targets.
> 
> I hope this explains the rationale.
> 
> FX
> 


OK, that makes sense.  I wonder if a comment to that effect is warranted 
somewhere.

One tricky thing about aarch64 IEEE support is that trapping exceptions 
(raising a software exception, as opposed to just setting an exceptional 
condition bit in the FPSR) is implementation defined.  The only way to 
tell if your implementation can support trapping an exception is to try 
to set the trapping enable bit in the FPCR.  If the bit is read back and 
is non-zero then that exception supports trapping; if it reads back as 
zero, then trapping that exception is not supported.  More details can 
be found in the armv8 Arm ARM.

HTH,

R.

  reply	other threads:[~2021-12-08 16:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 16:32 FX
2021-12-08 15:36 ` Richard Earnshaw
2021-12-08 15:47   ` FX
2021-12-08 16:08     ` Richard Earnshaw [this message]
2021-12-15  8:59 ` FX
2021-12-19 21:03 ` Thomas Koenig
2021-12-19 23:50   ` FX

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=db90b91c-b577-4f51-521d-63ad76d1e255@foss.arm.com \
    --to=richard.earnshaw@foss.arm.com \
    --cc=fortran@gcc.gnu.org \
    --cc=fxcoudert@gmail.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).