From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id E612C3858D1E for ; Fri, 30 Sep 2022 18:21:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E612C3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,358,1654588800"; d="scan'208";a="86721543" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 30 Sep 2022 10:21:08 -0800 IronPort-SDR: IXOvdbWoX082V262R6iXb5XmwUNp5HG9fZwNt5di+cOOazo03tCugsRQPW6ASs28CTfU8gnzpt Ici2EBGZ+bSmSdeOq5hvw6zq9/OI9mvr58Tzas/vj2lT0tnVT+yzvYnx7t+Y0wbIAqG5S6U8Xm 7qmkPBplAQCPhic12rsQjlRawymZ1a4iTCQvYqF6g2pCPrUka/f/ccbECD3w0E/NcdJE7PLHNK q6GYj0LXap/1lvkRHuwEXs6z8mg9ftW8NaF6XpDUP4iiotRuP+04222eMfLMVk1JwEuwuGOoe9 VzE= Date: Fri, 30 Sep 2022 18:21:04 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk 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 In-Reply-To: Message-ID: References: <37522634-319a-b471-aa35-87e711b0479e@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3111.0 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 and > 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 joseph@codesourcery.com