public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sjoerd Meijer <Sjoerd.Meijer@arm.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>,
	Joseph Myers <joseph@codesourcery.com>
Cc: Kito Cheng <kito.cheng@gmail.com>, GCC <gcc@gcc.gnu.org>
Subject: Re: IEEE Interchange floating point and extended floating point for C++
Date: Mon, 15 Mar 2021 10:16:56 +0000	[thread overview]
Message-ID: <DB6PR0801MB19902978F88A03A5FC38E4AFFC6C9@DB6PR0801MB1990.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAH6eHdQ+24Mkm51SsmPj+AOFE3Za0RVmKGmgbhGsA4Aow4nX=Q@mail.gmail.com>

Many thanks for your replies and thoughts on this.

I wanted to add that I agree with this, and say that this is the
current state in Clang (exactly because of the reason that
_Float16 is entirely new):
I see less value in adding additional distinct types that don't add anything you can't already do. _Float16 gives you access to an entirely new data type. _Float32 just complicates overloading of it's a new type with the same representation as an existing one. With the proposed std::float32 typedef for C++ users will still be able to write code that definitely uses an IEEE binary32 type without needing a new type to be introduced. ISTM that what users really want is "a type guaranteed to be IEEE binary32" and whether that is float or _Float32 is mostly irrelevant.
And isn't the good news that this is all fairly orthogonal
and a start could be made with _Float16 and others could be
added later if required?

Cheers,
Sjoerd.

________________________________
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Sent: 12 March 2021 22:03
To: Joseph Myers <joseph@codesourcery.com>
Cc: Sjoerd Meijer <Sjoerd.Meijer@arm.com>; Kito Cheng <kito.cheng@gmail.com>; GCC <gcc@gcc.gnu.org>
Subject: Re: IEEE Interchange floating point and extended floating point for C++



On Fri, 12 Mar 2021, 21:55 Joseph Myers, <joseph@codesourcery.com<mailto:joseph@codesourcery.com>> wrote:
On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:

> I see less value in adding additional distinct types that don't add
> anything you can't already do. _Float16 gives you access to an entirely new
> data type. _Float32 just complicates overloading of it's a new type with

So would you then support _Float128, and the corresponding f128/F128
literal suffixes, in C++, as a "more standard" version of __float128, in
the case where it has a different format from long double (e.g. x86_64)
but not when it has the same format as long double?

Or support it in both cases, but for the latter case as an alias for long double rather than as a distinct type.

I can ask the WG21 Numerics study group what they think makes sense for C++, because I'm not certain my choices are the right ones.

  reply	other threads:[~2021-03-15 10:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11  9:07 Kito Cheng
2021-03-11 12:56 ` Jonathan Wakely
2021-03-11 14:02   ` Gabriel Ravier
2021-03-11 15:14     ` Jonathan Wakely
2021-03-11 15:14       ` Jonathan Wakely
2021-03-12  6:50         ` Kito Cheng
2021-03-11 14:26 ` Joseph Myers
2021-03-12  7:17   ` Kito Cheng
2021-03-12  9:27   ` Jonathan Wakely
2021-03-12 11:42 ` Sjoerd Meijer
2021-03-12 12:31   ` Jonathan Wakely
2021-03-12 17:49     ` Joseph Myers
2021-03-12 18:14       ` Joseph Myers
2021-03-12 20:53         ` Jonathan Wakely
2021-03-12 21:55           ` Joseph Myers
2021-03-12 22:03             ` Jonathan Wakely
2021-03-15 10:16               ` Sjoerd Meijer [this message]
2021-03-15 10:20                 ` 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=DB6PR0801MB19902978F88A03A5FC38E4AFFC6C9@DB6PR0801MB1990.eurprd08.prod.outlook.com \
    --to=sjoerd.meijer@arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=jwakely.gcc@gmail.com \
    --cc=kito.cheng@gmail.com \
    /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).