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.129.124]) by sourceware.org (Postfix) with ESMTPS id 0E9273858403 for ; Mon, 12 Sep 2022 20:52:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E9273858403 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=1663015963; 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=C2fXNLYEEmrxzNDqi1wdXF7Ei2h3lkdojALfCtRZWTc=; b=gkTEYSbTJkOL/GKatmy5Dhc2JdXLS/KF82e9EKNLm2kCPQiacA0yr0lzGIbyharzHbhJVG mM5mkc/IB5676asbOcrFxZYDKZDQZvkr2mkRM9aWj7W7gz6p7MliIikvoGCZDVPup1lrmV PaxcQw57BsCYq2Yq/gi1LfZIl5I6lJ8= 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-327-_zWPZ5BhNdKOv2TvY_68UA-1; Mon, 12 Sep 2022 16:52:40 -0400 X-MC-Unique: _zWPZ5BhNdKOv2TvY_68UA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 384303C10141; Mon, 12 Sep 2022 20:52:40 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E8BB2C15BA4; Mon, 12 Sep 2022 20:52:39 +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 28CKqati408608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 12 Sep 2022 22:52:37 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28CKqZKn408607; Mon, 12 Sep 2022 22:52:35 +0200 Date: Mon, 12 Sep 2022 22:52:35 +0200 From: Jakub Jelinek To: Joseph Myers Cc: 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.8 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 07:36:05PM +0000, Joseph Myers wrote: > 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. Ok, makes sense, especially if it is applied on the glibc side a few months after it is changed on the GCC side. If it is applied immediately, there could be people who have 2 weeks old GCC trunk snapshot and try it with latest glibc, but if it will be say in December, it will be far less likely. > > 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.) Looking at HW instructions, I believe x86 F16C VCVTPH2PS and VCVTPS2PH raise invalid on SNaN and turn it into QNaN and from what I can understand, the AVX512F16 conversion insns like VCVTSH2SS and VCVTSS2SH do too, but AVX512_BF16 VCVTNE2PS2BF16 doesn't raise any exceptions (and there is no insn for the other direction). > > (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). 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. Jakub