From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 47DE53833098; Thu, 15 Dec 2022 18:01:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47DE53833098 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 2BFHxoA6005483; Thu, 15 Dec 2022 11:59:50 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BFHxnWF005482; Thu, 15 Dec 2022 11:59:49 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 15 Dec 2022 11:59:49 -0600 From: Segher Boessenkool To: Jakub Jelinek Cc: "Kewen.Lin" , Michael Meissner , gcc-patches@gcc.gnu.org, 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: <20221215175949.GV25951@gate.crashing.org> References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,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: Hi! On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote: > On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote: > > 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. IEEE QP and double-double cannot be ordered, neither represents a subset of the other. But the current middle end does require a total ordering for all floating point types (that can be converted to each other). Mike's precision hack was supposed to give us some time until an actual fix was made. But no one has worked on that, and there have been failures found with the precision hack as well, it worked remarkably well but it isn't perfect. We cannot move forward in a meaningful way until these problems are fixed. We can move around like headless chickens some more of course. Segher