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 9685F3858D33 for ; Wed, 22 Apr 2020 16:20:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9685F3858D33 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03MG4sJI114180; Wed, 22 Apr 2020 12:20:41 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 30jrxkruma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 12:20:41 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 03MGIx81020293; Wed, 22 Apr 2020 16:20:40 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma04wdc.us.ibm.com with ESMTP id 30fs66jqxb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 16:20:40 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 03MGKdpw41091446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 16:20:39 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C98C513604F; Wed, 22 Apr 2020 16:20:39 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 60692136053; Wed, 22 Apr 2020 16:20:39 +0000 (GMT) Received: from [9.85.170.199] (unknown [9.85.170.199]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 22 Apr 2020 16:20:39 +0000 (GMT) Subject: Re: [PATCH v3 6/6] powerpc64le: Enable support for IEEE long double To: Florian Weimer , "Paul E. Murphy via Libc-alpha" References: <87v9lrimbr.fsf@mid.deneb.enyo.de> From: Paul E Murphy Message-ID: Date: Wed, 22 Apr 2020 11:20:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <87v9lrimbr.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 spamscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220122 X-Spam-Status: No, score=-20.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 16:20:46 -0000 On 4/22/20 10:15 AM, Florian Weimer wrote: > * Paul E. Murphy via Libc-alpha: > >> diff --git a/NEWS b/NEWS >> index 07da1545b4..a54c0e0f65 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -14,6 +14,11 @@ Major new features: >> * The GNU C Library now loads audit modules listed in the DT_AUDIT and >> DT_DEPAUDIT dynamic section entries of the main executable. >> >> +* powerpc64le supports IEEE128 long double libm/libc redirects when >> + using the -mabi=ieeelongdouble to compile C code on supported GCC >> + toolchains. It is recommended to use GCC 8 or newer when testing >> + this option. > > Why do you write “testing this option”? > > To me, this implies that the feature is not ready yet. Is that the > case? > I still consider the IEEE128 ldouble feature experimental on ppc64le. Thus, why we need to explicitly invoke extra compiler options today. This is another necessary step towards maturing the feature. The ABI needs to be stablized to continue gcc enablement, and I think the ABI piece is ready.