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 647B03839602 for ; Wed, 14 Dec 2022 10:34:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 647B03839602 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=1671014046; 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=ffVNh/jn4HnIoJqJWIHhIm402oEn30yBbGIpyZhdurQ=; b=NTFf9x7FbQNYDgs1IUOHB3pn+dxsb6LbKX6tH1P9Lxe1WIdqnaWuQ9Xs2qgvhT5OyyGNF0 8JQ49ZFtD7jAZ9kxjqdfsQdKxJG1z/GGlkjkIU0FrcUJYDK5TVcYDDwvXYOfdUVK4+JNpj O0ZasWPon7rnFDhzVJvPAIz5OPFMbMI= 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-551-EXiDVoVSOKOTO_pYfv-exg-1; Wed, 14 Dec 2022 05:34:00 -0500 X-MC-Unique: EXiDVoVSOKOTO_pYfv-exg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 53C12801779; Wed, 14 Dec 2022 10:34:00 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E05E32166B26; Wed, 14 Dec 2022 10:33:59 +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 2BEAXrhB1134414 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 11:33:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2BEAXqc81134413; Wed, 14 Dec 2022 11:33:52 +0100 Date: Wed, 14 Dec 2022 11:33:51 +0100 From: Jakub Jelinek To: "Kewen.Lin" Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers Subject: Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Message-ID: Reply-To: Jakub Jelinek References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> <3cbaa3d2-4327-c62a-2904-eac5ca506d20@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: <3cbaa3d2-4327-c62a-2904-eac5ca506d20@linux.ibm.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote: > > The hacks with different precisions of powerpc 128-bit floating types are > > very unfortunate, it is I assume because the middle-end asserted that scalar > > floating point types with different modes have different precision. > > We no longer assert that, as BFmode and HFmode (__bf16 and _Float16) have > > the same 16-bit precision as well and e.g. C++ FE knows to treat standard > > vs. extended floating point types vs. other unknown floating point types > > differently in finding result type of binary operations or in which type > > comparisons will be done. > > It's good news, for now those three long double modes on Power have different > precisions, if they can have the same precision, I'd expect the ICE should be > gone. I'm talking mainly about r13-3292, the asserts now check different modes have different precision unless it is half vs. brain or vice versa, but could be changed further, but if the precision is the same, the FEs and the middle-end needs to know how to deal with those. For C++23, say when __ibm128 is the same as long double and _Float128 is supported, the 2 types are unordered (neither is a subset or superset of the other because there are many _Float128 values one can't represent in double double (whether anything with exponent larger than what double can represent or most of the more precise values), but because of the variable precision there are double double values that can't be represented in _Float128 either) and so we can error on comparisons of those or on arithmetics with such arguments (unless explicitly converted first). But for backwards compatibility we can't do that for __float128 vs. __ibm128 and so need to backwards compatibly decide what wins. And for the middle-end say even for mode conversions decide what is widening and what is narrowing even when they are unordered. Jakub