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 C215F3858403 for ; Mon, 12 Sep 2022 19:36:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C215F3858403 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,310,1654588800"; d="scan'208";a="85628281" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 12 Sep 2022 11:36:09 -0800 IronPort-SDR: aV9jEel/LoKXkLd0hQW1Zj/2O3/Pu3OZJgebp0g6HD2+u/7H5qHMroWtpoia4kC+hE40QSrdT4 T6iJJRVG6iNJWMPRwhzneRaLHC7Z6GxrsLBpSOsNG+HV3nyhGobOPbs1+KJ/WHI8KEMbWFKNUD MTjy9t4MaytA5uauIJoqVwgML97AzYTYxRN59h+EYY2Ft+xx91jYH4o8CyvA0rbKWIW/yO4Whx Ad08xT08QDuFOpG1Qu7adE2FnkbBlK2NauEZtWg1oP23wWS7/SelJr0A5CoCxqXfbjOk/FaRGu h3I= Date: Mon, 12 Sep 2022 19:36:05 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jakub Jelinek CC: Jason Merrill , Jonathan Wakely , Bruce Korb , Subject: Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652] In-Reply-To: Message-ID: References: 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-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3111.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote: > Now, I guess for the fixincludes it could also use > # if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) > where earlier GCC 13 snapshots would not be doing the fixincludes, > but the question is what to use for upstream glibc, because > there will be 13.0 snapshots where C++ doesn't support _Float{16,32,64,128} > and where it is essential to use what glibc has been doing previously > and using the #else would fail miserably, and then 13.0 snapshots where it > does support it and where using the if would fail miserably. We don't claim in glibc to support old snapshots from master, so checking for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is fine. > Conversion from BFmode to SFmode is easy, left shift by 16 and ought to be > implemented inline, SFmode -> BFmode conversion is harder, Properly the right way for converting from BFmode to SFmode in the presence of -fsignaling-nans should depend on how the result is used. If it's used for arithmetic, it's OK to have converted a BFmode signaling NaN to an SFmode signaling NaN, but if e.g. the result is examined with issignaling or otherwise stored so it may be significant later whether the result is a quiet or signaling NaN, IEEE semantics would mean a signaling NaN should be a converted to a quiet NaN with "invalid" raised. Though I don't know how far hardware instructions for BFmode attempt to follow IEEE semantics. (Cf. powerpc single-precision load instructions whose effect is defined as a purely bitwise conversion from single to double precision, so that single-precision load and store of a signaling NaN never end up converting it to a quiet NaN even though the in-register format is double precision.) > (untested) and the question is if it should be implemented in libgcc > (and using soft-fp or not), or inline, or both depending on -Os. Also if you try to do a direct conversion between BFmode and HFmode, soft-fp's current support for conversions may not handle that case (where one type has wider exponent range and other type has higher precision). -- Joseph S. Myers joseph@codesourcery.com