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 6BE0F3858D32; Mon, 17 Oct 2022 21:33:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BE0F3858D32 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.95,192,1661846400"; d="scan'208";a="87724193" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 17 Oct 2022 13:33:06 -0800 IronPort-SDR: gpZZGPDE//mo5XapsG4vn0mbQsDdB/Jvizfl26KF8KjBlKHGJX53zwQMrR6QC4udFVzllhW7XD UdY8JhYcygBPrvWaFZn0PVV0w+T82O5es7yeMUw70rz7Ew8zvjuZIvR04AI5QPzV2pamBTXf4g tpj8Cr/paaabqhWEgzdzOsgZlJW9Lm/H5TY53+SQd8Im3MZBC6Ss1kb6bLixEVTkOYFO5Lx1DD d9GNTsm9OTI1Fw3gFWa8BI0Dc2GvbBq/fxn3GnJ2OoOP/auLkCq/4Qmfj96p2Z76JLnDUxH9pf sMc= Date: Mon, 17 Oct 2022 21:33:02 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jonathan Wakely CC: Jakub Jelinek , , Subject: Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t 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-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3110.6 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 Mon, 17 Oct 2022, Jonathan Wakely via Gcc-patches wrote: > > And I/O etc. support is missing, not sure I'm able to handle that and if it > > is e.g. possible to keep that support out of libstdc++.so.6, because what > > extended floating point types one has on a particular arch could change over > > time (I mean e.g. bfloat16_t support or float16_t support can be added > > etc.). > > Yes, I think we can add the I/O functions as always_inline because all > they're going to do is convert the argument to float, double, or long > double and then call the existing overloads. There will be no new > virtual functions. As with fma, note that doing conversions from strings to floating-point is a case where doing the operation on float and then narrowing is technically incorrect because double rounding can occur (the rounded float result can be half way between two values of the narrower type, without that being the exact mathematical result) but the operation should be correctly rounding. It's fine to use float or double operations in the other direction (floating-point to strings), of course. -- Joseph S. Myers joseph@codesourcery.com