From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 308D83858034 for ; Fri, 27 Aug 2021 02:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 308D83858034 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17R251U5045541; Thu, 26 Aug 2021 22:11:05 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0b-001b2d01.pphosted.com with ESMTP id 3appn98dfb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Aug 2021 22:11:05 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 17R27w8M006309; Fri, 27 Aug 2021 02:11:04 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma02wdc.us.ibm.com with ESMTP id 3ajs4fcvss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Aug 2021 02:11:04 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 17R2B3wP35979682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 Aug 2021 02:11:03 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0FB086E05D; Fri, 27 Aug 2021 02:11:03 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7E6566E050; Fri, 27 Aug 2021 02:11:02 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.31.187]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTPS; Fri, 27 Aug 2021 02:11:02 +0000 (GMT) Date: Thu, 26 Aug 2021 22:10:58 -0400 From: Michael Meissner To: Joseph Myers Cc: Andreas Schwab , Patrick McGehearty via Gcc-patches , segher@kernel.crashing.org Subject: Re: [PATCH v3] Fix for powerpc64 long double complex divide failure Message-ID: Mail-Followup-To: Michael Meissner , Joseph Myers , Andreas Schwab , Patrick McGehearty via Gcc-patches , segher@kernel.crashing.org References: <1628784193-9675-1-git-send-email-patrick.mcgehearty@oracle.com> <87sfze70k0.fsf@igel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: LmlUa5nm3BE6Ctz6EkqCkMKXDIGlcWVR X-Proofpoint-ORIG-GUID: LmlUa5nm3BE6Ctz6EkqCkMKXDIGlcWVR X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-26_05:2021-08-26, 2021-08-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 spamscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1011 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108270009 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 02:11:09 -0000 On Fri, Aug 13, 2021 at 05:22:47PM +0000, Joseph Myers wrote: > On Fri, 13 Aug 2021, Andreas Schwab wrote: > > > On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote: > > How can it happen that __LONG_DOUBLE_IEEE128__ is not defined? This > > file is always compiled with -mfloat128 and this looks like dead code. > > I think the answer there is that -mfloat128 serves to enable __float128, > it doesn't change the long double ABI, which is what > __LONG_DOUBLE_IEEE128__ refers to (that's what -mabi=ieeelongdouble does). Yes this is correct. The -mfloat128 enables the __float128 keyword. It does not change the default long double format. Particularly before glibc 2.32 came out we had some software packages that saw that we had had __float128, and added functions to their library that took __float128 arguments. Unfortunately until the library had the support, it meant they would have references to things not yet implemented. We only enable -mfloat128 by default on 64-bit Linux systems. The macro __LONG_DOUBLE_IEEE128__ is defined when long double uses the IEEE 128-bit format. The macro __LONG_DOUBLE_IBM128__ is defined when long double uses the IBM 128-bit format. The macro __LONG_DOUBLE_128__ is defined when one of the 128-bit long double types (IBM or IEEE) is used for long double. You can change the long double format with the -mabi=ieeelongdouble option or by configuring the compiler with the --with-long-double-format=ieee configuration option. At present, only the C and C++ languages will work if you use the -mabi=ieeelongdouble option and your GLIBC is at least 2.32. This is because the library support has been done to allow building both ibm128 and IEEE 128-bit functions in the library, and the compiler will use the appropriate names based on the options. Other languages such as fortran cannot be configured during compilation and you must configure the compiler with the --with-long-double-format=ieee option. This is because those libraries and compilers have not been modified to have support for both 16-byte long double formats. You will need to use at least GLIBC 2.32. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797