From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2E98F3858C50 for ; Mon, 17 Oct 2022 21:50:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E98F3858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666043426; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=U9tFcZVg3v3Nu2rZgSstqRTi1ujI/Gpil5WALwDWq/k=; b=Z4ihqAas80JVukwg9gzkSSTlO58SP03q//n32oJiXNcD+rJGIp/14EzBNYyra+eACzGNMN qmk4Q6uprjUEaehWgvDZlJf8yVtdXbyw1jHhBbec1TomJs8vPxJB1rv+CKMPZ55zYaHwKB utCS166Elfg9bjBy5s1x2VW0VpIxlmo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-410-7i1Zv6-dP86cXn5LBGSOOw-1; Mon, 17 Oct 2022 17:50:22 -0400 X-MC-Unique: 7i1Zv6-dP86cXn5LBGSOOw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6B053833A0F; Mon, 17 Oct 2022 21:50:22 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 295D31121319; Mon, 17 Oct 2022 21:50:21 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29HLoJLe1673801 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 17 Oct 2022 23:50:19 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29HLoIGO1672050; Mon, 17 Oct 2022 23:50:18 +0200 Date: Mon, 17 Oct 2022 23:50:17 +0200 From: Jakub Jelinek To: Joseph Myers Cc: Jonathan Wakely , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable 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, Oct 17, 2022 at 09:33:02PM +0000, Joseph Myers 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. That is true, but for istream and ostream that is what the standard requires. This is because there are required facets to be called and they are available just for float/double/long double and it would be an ABI change to allow more. For extended floating point wider than long double it is implementation defined what happens. And otherwise, there is [ Note: When the extended floating-point type has a floating-point conversion rank that is not equal to the rank of any standard floating-point type, then double rounding during the conversion can result in inaccurate results. from_chars can be used in situations where maximum accuracy is important. - end note ] As for , I think we'll need to implement both directions, though perhaps the float16_t or bfloat16_t to_chars can be partly or fully implemented using the float to_chars. Jakub