public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jonathan Wakely <jwakely@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>
Cc: Jason Merrill <jason@redhat.com>,
	Richard Earnshaw <richard.earnshaw@arm.com>,
	richard.sandiford@arm.com, gcc-patches@gcc.gnu.org
Subject: Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support
Date: Fri, 30 Sep 2022 20:38:45 +0200	[thread overview]
Message-ID: <Yzc3tc7gPPORTdQY@tucnak> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2209301804390.609132@digraph.polyomino.org.uk>

On Fri, Sep 30, 2022 at 06:21:04PM +0000, Joseph Myers wrote:
> On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> 
> > What isn't in the patch but I think we'll need to also change are some
> > minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
> > all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> > no glibc support for any of that, so builtins that are expanded by the
> > compiler are fine, but what should be fall back to libm won't work.
> > Maybe at least for now it is acceptable to implement most <cmath> and
> > <complex> std::float16_t and std::bfloat16_t overloads with using
> > __builtin_*f and explicitly narrow down, but I think at least nextafter
> > (and apparently nexttoward as an alias for it for extended floating
> > point types) needs to be specific for the particular floating point format.
> 
> C doesn't have nexttoward (the function whose second argument is always 
> long double, independent of the type of the first argument) for any of the 
> _FloatN or _FloatNx types; why does C++ have in (but with second argument 
> the same type as the first?) for those types?

No idea.
https://eel.is/c++draft/cmath.syn
has (since that std::float*_t/std::bfloat16_t paper)
constexpr floating-point-type nextafter(floating-point-type x, floating-point-type y);
constexpr float nextafterf(float x, float y);
constexpr long double nextafterl(long double x, long double y);

constexpr floating-point-type nexttoward(floating-point-type x, floating-point-type y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);

That is certainly wrong for double, because it is a backwards incompatible
change, where
constexpr double nexttoward(double x, long double y);
is gone and
constexpr double nexttoward(double x, double y);
is added.
IMHO the nexttoward case just shouldn't be changed, so it should remain:
constexpr float nexttoward(float x, long double y);
constexpr double nexttoward(double x, long double y);
constexpr long double nexttoward(long double x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
Having
constexpr floating-point-type nexttoward(floating-point-type x, long double y);
would be problematic, because long double might have unordered floating
point rank to floating-point-type (say powerpc IBM extended long double
vs. std::float128_t), or could have smaller floating point rank (say if
it is IEEE double).
But like nexttowardl or nexttoward(long double, long double) aren't very
useful because they are the same thing as nextafterl or
nextafter(long double, long double), introducing other nexttoward overloads
doesn't seem useful.

	Jakub


  reply	other threads:[~2022-09-30 18:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 15:55 Jakub Jelinek
2022-09-30 13:49 ` Jason Merrill
2022-09-30 14:08   ` Jakub Jelinek
2022-09-30 18:21     ` Joseph Myers
2022-09-30 18:38       ` Jakub Jelinek [this message]
2022-09-30 19:27         ` Jonathan Wakely
2022-10-04  9:06     ` [PATCH] middle-end, c++, i386, " Jakub Jelinek
2022-10-04 15:54       ` Joseph Myers
2022-10-04 21:50       ` Jason Merrill
2022-10-05 13:47         ` Jakub Jelinek
2022-10-05 20:02           ` Jason Merrill
2022-10-12  8:23             ` [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE Jakub Jelinek
2022-10-12 10:15               ` Richard Sandiford
2022-10-12 11:07                 ` [PATCH] machmode, v2: " Jakub Jelinek
2022-10-12 11:49                   ` Richard Sandiford
2022-10-12 10:37               ` [PATCH] machmode: " Eric Botcazou
2022-10-12 10:57                 ` Jakub Jelinek
2022-10-13 16:50             ` [PATCH] middle-end, c++, i386, libgcc, v2: std::bfloat16_t and __bf16 arithmetic support Jakub Jelinek
2022-10-13 19:37               ` Jason Merrill
2022-10-13 21:11                 ` Uros Bizjak
2022-10-13 21:35                   ` Jakub Jelinek
2022-10-13 21:46                     ` Uros Bizjak

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=Yzc3tc7gPPORTdQY@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=jwakely@redhat.com \
    --cc=richard.earnshaw@arm.com \
    --cc=richard.sandiford@arm.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).