From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 7DD62385801A for ; Wed, 10 Aug 2022 21:38:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DD62385801A Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27ALbwMw007011; Wed, 10 Aug 2022 21:38:18 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hvm1ms1ne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 21:38:18 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27ALc0jC007531; Wed, 10 Aug 2022 21:38:17 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hvm1ms1ms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 21:38:17 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27ALLwpv008203; Wed, 10 Aug 2022 21:38:16 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma04dal.us.ibm.com with ESMTP id 3huwvw8nq0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 21:38:16 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27ALcF7H3015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Aug 2022 21:38:15 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE5AF112069; Wed, 10 Aug 2022 21:38:15 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7280F112062; Wed, 10 Aug 2022 21:38:15 +0000 (GMT) Received: from linux.ibm.com (unknown [9.160.115.156]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 10 Aug 2022 21:38:15 +0000 (GMT) From: Tulio Magno Quites Machado Filho To: Segher Boessenkool , Michael Meissner Cc: Jakub Jelinek , Michael Meissner via Gcc , Mike Stump , Iain Sandoe , "Carlos O'Donell" , libc-alpha@sourceware.org, Alan Modra , Joseph Myers , "David S. Miller" , Jeff Law , Richard Biener , Nathan Sidwell Subject: Re: Resend: Potential upcoming changes in mangling to PowerPC GCC In-Reply-To: <20220810200400.GD25951@gate.crashing.org> References: <871qtnc1q9.fsf@linux.ibm.com> <20220810200400.GD25951@gate.crashing.org> User-Agent: Notmuch/0.36 (http://notmuchmail.org) Emacs/27.2 (x86_64-redhat-linux-gnu) Date: Wed, 10 Aug 2022 18:38:14 -0300 Message-ID: <87y1vvaiex.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: j6B3FICfNgCkFO0WgmuKCSwZDjrT2Hxt X-Proofpoint-GUID: D9uSShD6_BAFDBw2zh7uQ2-wVrtJK9DN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-10_14,2022-08-10_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 mlxlogscore=669 lowpriorityscore=0 clxscore=1015 bulkscore=0 impostorscore=0 mlxscore=0 phishscore=0 priorityscore=1501 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208100064 X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 21:38:25 -0000 Segher Boessenkool writes: > You can write > double convert (__ibm128 x) { return x; } > double convert (__ieee128 x) { return x; } > as well. "__ieee128" and "long double" are the same type then (and the > same as _Float128 and __float128 as well). Oh! I see. Thanks! Going back to Mike's original question: >> But in changing the mangling, we have the potential to create compatibility >> issues, of code compiled with previous GCC's that use explicit __ibm128 and >> __float128 keywords. I don't how the users of these keywords (i.e. typically >> libstdc++ and glibc developers, but potentially others as well). In glibc, we use __ibm128 only once in a place that always has to be double-double regardless of the long double type. Everywhere else, when a double-double type is expected, long double is used. This is also how glibc users are expected to use double-double functions from glibc. Meanwhile, _Float128/_float128 is used everywhere along with long double, regardless if long double is double-double or __float128. With that said, glibc code was designed with this in mind (thanks Joseph!), but AFAIK nobody ever tested building glibc for ppc64le with the proposal you have here. If this proposal is adopted, we'd need a way to distinguish between the previous and the new behavior, i.e. a macro. Anyway, I believe that a newer GCC will have trouble compiling on a system with an older glibc. An older glibc will also have trouble building with a newer GCC, but that might be less important. Likewise for libdfp. -- Tulio Magno