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 4BAC03832BBD for ; Wed, 14 Dec 2022 09:36:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BAC03832BBD 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=1671010578; 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=QLKMVYFtjxWMhpSIU2BHMMe7DVlPVaiak7vVDiui0dY=; b=YiTzVpArxWuUUsO+6msmeD7WS9gOzn4emZVs4GI+mEFYTJLtKmBydVC0UoqcFwTidzK/yz qCc9OHdV07nzs+7FK0LRGf8J4lAAEPUu4rVfPPuRbUrVgaedAND/HVv6Vcd0kQX2mDULT2 41pbhaAgkNljse2sdr0f/Zk2nZ4wDzc= 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-358-A3HUI91NNp-mHArflaZVKA-1; Wed, 14 Dec 2022 04:36:12 -0500 X-MC-Unique: A3HUI91NNp-mHArflaZVKA-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 616AB80234E; Wed, 14 Dec 2022 09:36:12 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D1C5B2166B26; Wed, 14 Dec 2022 09:36:11 +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 2BE9a5X01134225 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 10:36:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2BE9a3X41134224; Wed, 14 Dec 2022 10:36:03 +0100 Date: Wed, 14 Dec 2022 10:36:03 +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> MIME-Version: 1.0 In-Reply-To: <6b7325c6-6416-d64f-89a8-7341aeb8226c@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 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote: > on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote: > > Hi Mike, > > > > Thanks for fixing this, some comments are inlined below. > > > > on 2022/11/2 10:42, Michael Meissner wrote: > >> This patch fixes the issue that GCC cannot build when the default long double > >> is IEEE 128-bit. It fails in building libgcc, specifically when it is trying > >> to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc > >> during the evrp pass. Ultimately it is failing because the code declared the > >> type to use TFmode but it used F128 functions (i.e. KFmode). > > By further looking into this, I found that though __float128 and _Float128 types > are two different types, they have the same mode TFmode, the unexpected thing is > these two types have different precision. I noticed it's due to the "workaround" > in build_common_tree_nodes: > > /* Work around the rs6000 KFmode having precision 113 not > 128. */ > const struct real_format *fmt = REAL_MODE_FORMAT (mode); > gcc_assert (fmt->b == 2 && fmt->emin + fmt->emax == 3); > int min_precision = fmt->p + ceil_log2 (fmt->emax - fmt->emin); > if (!extended) > gcc_assert (min_precision == n); > if (precision < min_precision) > precision = min_precision; > > Since function useless_type_conversion_p considers two float types are compatible > if they have the same mode, so it doesn't require the explicit conversions between > these two types. I think it's exactly what we want. And to me, it looks unexpected > to have two types with the same mode but different precision. > > So could we consider disabling the above workaround to make _Float128 have the same > precision as __float128 (long double) (the underlying TFmode)? I tried the below > change: 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. That said, we'd need some target hooks to preserve the existing behavior with __float128/__ieee128 vs. __ibm128 vs. _Float128 with both -mabi=ibmlongdouble and -mabi=ieeelongdouble. I bet the above workaround in generic code was added for a reason, it would surprise me if _Float128 worked at all without that hack. Shouldn't float128_type_node be adjusted instead the same way? Jakub