public inbox for
 help / color / mirror / Atom feed
From: Joseph Myers <>
To: Jakub Jelinek <>
Cc: Jason Merrill <>,
	Jonathan Wakely <>,
	Richard Earnshaw <>,
	<>, <>
Subject: Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support
Date: Fri, 30 Sep 2022 18:21:04 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Yzb4SikTcfSimsIn@tucnak>

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?

(C2x also doesn't have fmax or fmin for the _FloatN or _FloatNx types, but 
that's because the operations those are bound to are replaced in IEEE 
754-2019 by different max/min operations with different corresponding 
functions; glibc still provides the fmax and fmin operations for _FloatN 
and _FloatNx, as in TS 18661-3, as extensions.)

Providing a full set of _Float16 operations in glibc would be reasonable 
(modulo the issues with implications for the minimum GCC version for 
building glibc for a given architecture).  It's rather less clear that 
__bf16 operations would be appropriate.

There may also be double rounding considerations for implementing some 
functions (that are required to be correctly rounded) via operations on 
float; at least for fma (if the result of fmaf is half way between two 
representable values of the narrower type, but not exactly equal to the 
value of a*b+c).

Joseph S. Myers

  reply	other threads:[~2022-09-30 18:21 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 [this message]
2022-09-30 18:38       ` Jakub Jelinek
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* 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).