From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id DCFF83852C7A; Tue, 13 Dec 2022 06:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCFF83852C7A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BD5ePXo016373; Tue, 13 Dec 2022 06:14:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=JX+Q9sC4LPvlAaZyFj6Ct/bLxYzekuzKpP56QViBv1M=; b=GywCAQxXQ7jUmFY468aPZ0JnlmDirF4vC89WcJ4/Syxri+ep/JokKQePrqaGoyGfZCna raFr4pmRLNMPjHMvIBPQcUWvh2CeBUwLS0/BKzJzUxE+Sw+5WPZAlovGptFkGhKrCpoV 9BkmgHr9IK5ri8cSxpil/soL/5XHNXizF5mINCYdsXJ5N7fYp4OkJkd+BK4GoAiMrkpS XJFTsxGUC+Y+d4K21yetS3IL++7n7bwkGRxiSj3awmYeml8rkrScPoylySSWvfdIMptH 6Se+NZb8I0aJE6Po8wPXvgL4wVXP8mQtyd/s2jA3/+baPiobZEby3XPLV4HIcqTrvnJJ 5Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mejm39t83-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Dec 2022 06:14:45 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BD5ftnN023204; Tue, 13 Dec 2022 06:14:45 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mejm39t7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Dec 2022 06:14:45 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.16.1.2) with ESMTP id 2BD4FePt019493; Tue, 13 Dec 2022 06:14:44 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([9.208.129.120]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3mchr6p359-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Dec 2022 06:14:44 +0000 Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BD6Efi766388298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Dec 2022 06:14:41 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BF8E558054; Tue, 13 Dec 2022 06:14:41 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC3535803F; Tue, 13 Dec 2022 06:14:40 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Tue, 13 Dec 2022 06:14:40 +0000 (GMT) Date: Tue, 13 Dec 2022 01:14:39 -0500 From: Michael Meissner To: "Kewen.Lin" Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , William Seurer , Will Schmidt , Peter Bergner Subject: Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299 Message-ID: Mail-Followup-To: Michael Meissner , "Kewen.Lin" , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , William Seurer , Will Schmidt , Peter Bergner References: <997752a6-8cd4-abc5-d6e3-2e75eaa37d57@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 6_if6i-LhbCg7qjZTJIJGXSPpbfBOHVn X-Proofpoint-GUID: Zko8A-cc5w6RK9Ta1tipq27NGvAZ9Nqi X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-13_02,2022-12-12_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 spamscore=0 phishscore=0 mlxscore=0 suspectscore=0 clxscore=1015 mlxlogscore=597 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212130055 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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: On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote: > Without or with patch #1, the below ICE in libgcc exists, the ICE should have > nothing to do with the special handling for building_libgcc in patch #1. I > think patch #2 which makes _Float128 and __float128 use the same internal > type fixes that ICE. > > I still don't get the point why we need the special handling for building_libgcc, > I also tested on top of patch #1 and #2 w/ and w/o the special handling for > building_libgcc, both bootstrapped and regress-tested. > > Could you have a double check? As long as patch #2 and #3 are installed, we don't need the special handling for building_libgcc. Good catch. I will send out a replacement patch for it. > Since your patch #2 (and #3) fixes ICE and some exposed problems, and _Float128 > is to use the same internal type as __float128, types with attribute((mode(TF))) > and attribute((mode(TC))) should be correct, I assume that this patch is just > to make the types explicit be with _Float128 (for better readability and > maintainance), but not for any correctness issues. Yes, the patch is mainly for clarity. The history is the libgcc support went in before _Float128 went in, and I never went back to use those types when we could use them. With _Float128, we can just use _Complex _Float128 and not bother with trying to get the right KC/TC for the attribute mode stuff. However, if patches 1-3 aren't put in, just applying the patch to use _Float128 and _Complex _Float128 would fix the immediate problem (of not building GCC on systems with IEEE 128-bit long double). However, it is a band-aid that just works around the problem of building __mulkc3 and __divkc3. It doesn't fix the other problems between __float128 and _Float128 that show up in some places that I would like to get fixed. So I haven't submitted the patch, because I think it is more important to get the other issues fixed. > > Now, this patch fixes the specific problem of not being able to build libgcc > > (along with patch #1 of the series). But other things show the differences > > from time time because we are using different internal types and the middle end > > doesn't know that these types are really the same bits. > > > > It is better long term (IMHO) if we have the two types (__float128 and > > _Float128) use the same internal type (which is what is done in patches #2 and > > #3). This fixes the other issues that show up, such as creating signaling NaNs > > for one internal type, and converting it to the other internal type, loses that > > the NaN is signalling. > > > > I see, nice! > > BR, > Kewen -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com