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 F127A3858403 for ; Mon, 12 Sep 2022 21:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F127A3858403 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=1663016440; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=Mi7P5vH2q/i4pg3tjgjx8ShOzsr3HZg+yY7xgm4g0qY=; b=C49NM6ojhIU3SwGkQbJJ2BMLd9eBNd7r61nzcRIELj8Wr1a67iZXbYXOSrRYFNjKbcpRLq RgBHh6tKIMfsYmNnxfyGFuM730HC8cbGqw/4jBp9Wj17y6sCJfhfRC4FGZLsMTjjMyeF3o brIubqLLwQvXqS8/qvlBNhoQrohdze4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-612-uWK4dchfP7GapnKWsP0wdA-1; Mon, 12 Sep 2022 17:00:37 -0400 X-MC-Unique: uWK4dchfP7GapnKWsP0wdA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 126141C07546; Mon, 12 Sep 2022 21:00:37 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BF0382027061; Mon, 12 Sep 2022 21:00:36 +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 28CL0Yue408636 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 12 Sep 2022 23:00:34 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28CL0X0x408635; Mon, 12 Sep 2022 23:00:33 +0200 Date: Mon, 12 Sep 2022 23:00:33 +0200 From: Jakub Jelinek To: Joseph Myers , Jonathan Wakely , gcc-patches@gcc.gnu.org, Bruce Korb Subject: Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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, Sep 12, 2022 at 10:52:35PM +0200, Jakub Jelinek via Gcc-patches wrote: > Can't that be implemented as 2 conversions, convert BFmode to SFmode and > then back to HFmode (or the other way around)? > SFmode is a superset of both formats, so except for the raise exception on > SNaN and conversion to QNaN extension to SFmode from both formats should be > lossless? > > In any case, the bfloat16 support is intended maybe for follow-up patches, > not in this patch. Well, the BF -> HF conversion could be done just by << 16 + SF -> HF conversion too. But for BF -> HF and HF -> BF conversions (C++ allows them only for explicit casts, not implicit), the question is what library routine name to use, because it is neither pure extension nor pure truncation. But guess that is the case for PowerPC IFmode vs. KFmode. And the backend has both truncifkf2 and extendifkf2 named patterns which presumably do the same thing. Jakub