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 9A069383437C; Wed, 14 Dec 2022 08:45:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A069383437C 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 (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BE8fq0j032660; Wed, 14 Dec 2022 08:45:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : from : cc : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=08aXn86sSqJgw81phgHBR0pd1qk3Pu82d7MNRiftg44=; b=r4/XOa8btA4E/KWBfYduA3fg0EMLzgmg+x15+F7BRfxOxy7Oa7Bz9m947W1tqE1kFUh0 UXw67IHDdVMk+L8DyEFZS1h1hjo6hnjFpRAVeYWjzA9VGGeycsbxwRI+D66nBxsbX2GM FtolNzR51QnseboMezNRRNzd7H5hJBuGn/8nVsC4Vd5atwldug9X1OFuME7eQfPVPMxa 97Zg34wW5voKeAOPAb0gdG3aUy9ZftNm1PYZnPCBsu6Gj74Q38DUbbsRIbSObfx1vfou FA+J7dpUK2xosOakHXv+I4tZeNsTwYfCUFkebx+PhiQOJKwz+BcrSF1uPlN6wDGF09TV Pg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfb6xr2na-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:45:37 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BE8hGlP005258; Wed, 14 Dec 2022 08:45:36 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfb6xr2m8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:45:36 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BDJdZ1i013356; Wed, 14 Dec 2022 08:45:34 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma01fra.de.ibm.com (PPS) with ESMTPS id 3meyqxrhrt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:45:34 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BE8jUaW35520858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Dec 2022 08:45:30 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5DF4020043; Wed, 14 Dec 2022 08:45:30 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C9FFC20040; Wed, 14 Dec 2022 08:45:27 +0000 (GMT) Received: from [9.197.253.236] (unknown [9.197.253.236]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 14 Dec 2022 08:45:27 +0000 (GMT) Message-ID: <77050a4c-e34b-2116-6349-6560f4a9afd6@linux.ibm.com> Date: Wed, 14 Dec 2022 16:45:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299 Content-Language: en-US To: Michael Meissner References: <997752a6-8cd4-abc5-d6e3-2e75eaa37d57@linux.ibm.com> From: "Kewen.Lin" Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , William Seurer , Will Schmidt , Peter Bergner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: NSOciG6P_784If-xyny4pzG1XWvd6ObJ X-Proofpoint-GUID: W5fnFUMc9XlTCuhBeZ6MbT0C-rOY8Cs9 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-14_03,2022-12-13_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 phishscore=0 adultscore=0 clxscore=1015 suspectscore=0 spamscore=0 mlxscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=826 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212140066 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,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 2022/12/13 14:14, Michael Meissner wrote: > 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. Thanks! I still feel patch #1 is independent, it helps to fix the issues as shown in its associated test case, which looks an oversight in the previous implementation to me. :) > >> 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. OK, make sense, thanks for the clarification! BR, Kewen