public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dennis Clarke <dclarke@blastwave.org>
To: gcc-help@gcc.gnu.org
Subject: Re: making double type default to 80 or 128 bytes
Date: Fri, 7 Aug 2020 15:59:55 +0000	[thread overview]
Message-ID: <9a66e245-61cf-9eb2-f4f5-3fc7d10d9ff8@blastwave.org> (raw)
In-Reply-To: <ddf4798f-620e-531e-8bce-b31a08dedb2a@gmail.com>

On 8/7/20 2:59 PM, dave via Gcc-help wrote:
> 
> Is it possible to modify the gcc compiler so that recompiling existing
> code and libraries will produce longer doubles (80 or 128 bytes)
> 
> without having to re declare all the double types.  This may be a stupid
> question but I'm looking for a quick fix to see if extra
> 
> precision helps with an optimization problem. Thanks.

There is no such thng as an 80 byte double. The standards state that we
shall use floating point types which are of specific bit widths and all
of those are perfectly aligned on perfect power of two bit widths. These
range from 16 bits to 256 bit width. To date I have not seen hardware
which natively supports the 256-bit floating point type.  The IBM POWER9
processor as well as the RISC-V and Fujitsu SPARC provide hardware for
the 128-bit width and they seem to work very well indeed. The 80-bit
thing to which you refer is a hack put in place by the intel/x86 world
simply because the hardware can not properly handle anything larger. It
should not exist at all in if we use the floating point standards.

You are far better off using gmp and mpfr and mpc ( et. al. ) to attain
a wider degree of floating point precision but you will never get very
far using x86 hardware. It simply can not do that and the 80-bit hack is
just that, a hack.

Dennis

  parent reply	other threads:[~2020-08-07 16:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07 14:59 dave
2020-08-07 15:38 ` Dallman, John
2020-08-07 15:59 ` Dennis Clarke [this message]
2020-08-10 23:37   ` Jim Wilson
2020-08-07 18:23 ` Jonathan Wakely

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=9a66e245-61cf-9eb2-f4f5-3fc7d10d9ff8@blastwave.org \
    --to=dclarke@blastwave.org \
    --cc=gcc-help@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).