public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ada,FYI] revamp ada.numerics.aux
Date: Thu, 21 Jan 2021 06:57:31 -0300	[thread overview]
Message-ID: <orwnw6ipdg.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <a91665fe-bc62-a20f-4736-74abeb34b519@embedded-brains.de> (Sebastian Huber's message of "Thu, 21 Jan 2021 06:24:37 +0100")

On Jan 21, 2021, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:

> Which target properties determine that a-nallfl__wraplf.ads should be
> used?

The question really is what makes the default a-nallfl.ads unusable for
a target.  It works when the Ada type Long_Long_Float and the C long
double type are nop-convertible.  When they aren't, the attempt to
compile it will report mismatch between the functions declared with
Long_Long_Float, and the C intrinsics they're mapped to.

> Can it be used for all targets?

It would compile, but it shouldn't be used that way.  The wraplf
implementation uses wrappers of the Long_Float/C double implementations
of trigonometric and transcendental functions.  When Long_Long_Float and
Long_Float are different names for the same base FP types, that's ok,
but when Long_Long_Float is wider, the results may be unacceptably
imprecise.

in general, you can use wraplf when long double and double use the same
representation in C.  When they don't, one needs to tell whether GNAT
maps Long_Long_Float to long double or to double.  GNAT wants
Long_Long_Float to be as much of a hardware-supported type as
Long_Float, and the heuristics to accomplish that, in
gcc/ada/set_targ.adb:C_Type_For is to only use long double if it can
represent no more than 18 digits.

I believe this heuristics is to be revisited in a not-too-distant
future, but it's what it is ATM.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

  reply	other threads:[~2021-01-21  9:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-18 20:28 Alexandre Oliva
2020-10-19  9:46 ` Andreas Schwab
2020-10-19 11:52   ` Alexandre Oliva
2020-10-20  8:26     ` Rainer Orth
2020-10-22  5:15       ` Alexandre Oliva
2020-10-23  7:24       ` Iain Sandoe
2020-10-22  5:13     ` Alexandre Oliva
2020-10-22 18:13       ` Eric Botcazou
2020-10-23  9:33         ` Alexandre Oliva
2021-01-13  6:37     ` Sebastian Huber
2021-01-13 16:45       ` Alexandre Oliva
2021-01-13 17:27         ` Sebastian Huber
2021-01-13 18:40           ` Alexandre Oliva
2021-01-21  5:24             ` Sebastian Huber
2021-01-21  9:57               ` Alexandre Oliva [this message]
2020-10-22  5:22 ` Alexandre Oliva
2020-10-22 12:04   ` Alexandre Oliva
2020-10-23 14:23   ` move sincos after pre (was: Re: [Ada,FYI] revamp ada.numerics.aux) Alexandre Oliva
2020-10-23 15:05     ` move sincos after pre (was: Re: [Ada, FYI] " Richard Biener
2020-10-27  5:32       ` move sincos after pre Alexandre Oliva
2020-10-27  8:54         ` Richard Biener
2020-10-28  3:17           ` Alexandre Oliva
2020-10-28 13:01             ` Richard Biener
2020-12-22 22:03               ` make FOR_EACH_IMM_USE_STMT safe for early exits (was: Re: move sincos after pre) Alexandre Oliva
2021-01-04 13:10                 ` Richard Biener
2021-01-06 11:34                   ` make FOR_EACH_IMM_USE_STMT safe for early exits Alexandre Oliva
2021-01-07  8:41                     ` Richard Biener
2021-01-09 20:33                       ` Alexandre Oliva
2021-01-11  8:42                         ` Richard Biener
2021-01-12 14:29                         ` Andrew MacLeod
2020-10-22  5:27 ` [Ada,FYI] revamp ada.numerics.aux Alexandre Oliva

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=orwnw6ipdg.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=sebastian.huber@embedded-brains.de \
    /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).