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 E30BD3858D33 for ; Wed, 22 Feb 2023 10:37:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E30BD3858D33 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 (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31MAP6Ka039215; Wed, 22 Feb 2023 10:37:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : cc : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=Yth+XEGzWki3RD4ChkfUowjTAz447xOn42zOGDGsui0=; b=qHIUPgsVkpQdGbPfE97yAwcdqcEbiTBuO2HuE4uCxkwGO6uxyeb5Wa971pxHY3JEisug N6IX6kUg8gRhPLuvuj78/EC1AC+nBIG9aUZjLwKiVcwCBs2m6GwpH0FQrEKR0nNHzDJi q2lOUl1rbpz9hqx7HFVGw9CRBuALsI4Tdkx8vsoblVBErs4eT91O/lTxzasX7mJueh5a OaT4OkPzKC2PNn11SHvgJwR/wsM7S/jZfDxLmh+3dtZv8e2puVIPghfJZaX40m6lEcHm v4BA/BnrrhpFb6jIusPrgD26hJ498HzmhIghHgOCKD2J9zrrbpSpyZtY/08R0KGv4l+i BA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nwh9f89c9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:37:53 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 31MATSDO011888; Wed, 22 Feb 2023 10:37:52 GMT Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nwh9f89b6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:37:52 +0000 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 31MAMXeF008587; Wed, 22 Feb 2023 10:37:50 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma06fra.de.ibm.com (PPS) with ESMTPS id 3ntnxf3xue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:37:49 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 31MAbkoa46596506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Feb 2023 10:37:46 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AC68920040; Wed, 22 Feb 2023 10:37:43 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6996D20043; Wed, 22 Feb 2023 10:37:41 +0000 (GMT) Received: from [9.197.242.224] (unknown [9.197.242.224]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 22 Feb 2023 10:37:41 +0000 (GMT) Message-ID: Date: Wed, 22 Feb 2023 18:37:39 +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/2] PR target/107299: Fix build issue when long double is IEEE 128-bit Content-Language: en-US To: Michael Meissner References: Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , Will Schmidt From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Q60CslH_hqQnlb13UfBLfBgjVWbiyZkE X-Proofpoint-GUID: x9mcGLLtvWl0ULfgs8_xf93ifRuj-6Dy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-22_05,2023-02-22_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 spamscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxlogscore=659 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302220092 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Mike, on 2023/2/3 13:49, Michael Meissner wrote: > This patch is a repost of a patch: > > | Date: Thu, 19 Jan 2023 11:37:27 -0500 > | Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE 128-bit > | Message-ID: > > This patch updates the IEEE 128-bit types used in libgcc. > > At the moment, we cannot build GCC when the target uses IEEE 128-bit long > doubles, such as building the compiler for a native Fedora 36 system. The > build dies when it is trying to build the _mulkc3.c and _divkc3 modules. > > This patch changes libgcc to use long double for the IEEE 128-bit base type if > long double is IEEE 128-bit, and it uses _Float128 otherwise. The built-in > functions are adjusted to be the correct version based on the IEEE 128-bit base > type used. > > While it is desirable to ultimately have __float128 and _Float128 use the same > internal type and mode within GCC, at present if you use the option > -mabi=ieeelongdouble, the __float128 type will use the long double type and not > the _Float128 type. We get an internal compiler error if we combine the > signbitf128 built-in with a long double type. > > I've gone through several iterations of trying to fix this within GCC, and > there are various problems that have come up. I developed this alternative > patch that changes libgcc so that it does not tickle the issue. I hope we can > fix the compiler at some point, but right now, this is preventing people on > Fedora 36 systems from building compilers where the default long double is IEEE > 128-bit. Thanks for working on this! If updating libgcc source to workaround this issue is the best option we can have at this moment, it's fine. Comparing to one previous proposal which removes the workaround in build_common_tree_nodes for rs6000 KFmode, a bit concern on this one is that users can still meet the ICE with a simple case like: typedef float TFtype __attribute__((mode (TF))); TFtype test (TFtype t) { return __builtin_copysignf128 (1.0q, t); } but I guess they would write this kind of code very rarely? BR, Kewen