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 695BF3857C71 for ; Thu, 10 Sep 2020 18:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 695BF3857C71 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08AIdB9f086495; Thu, 10 Sep 2020 14:53:01 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33fsbv8msg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 14:53:01 -0400 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 08AIdGB8086945; Thu, 10 Sep 2020 14:53:01 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 33fsbv8ms4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 14:53:00 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08AIcBGB031237; Thu, 10 Sep 2020 18:53:00 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma04dal.us.ibm.com with ESMTP id 33c2a9vf9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 18:53:00 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08AIqx9L45810168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Sep 2020 18:52:59 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 67C7FAE05F; Thu, 10 Sep 2020 18:52:59 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 11D6AAE05C; Thu, 10 Sep 2020 18:52:59 +0000 (GMT) Received: from linux.ibm.com (unknown [9.65.204.29]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 10 Sep 2020 18:52:58 +0000 (GMT) From: Tulio Magno Quites Machado Filho To: Joseph Myers , "Carlos O'Donell" Cc: patsy@redhat.com, libc-alpha@sourceware.org, Matheus Salgueiro Castanho Subject: Re: [PATCH v2] powerpc: Update ULPs and output for j0 with ibm128 In-Reply-To: References: <20200909165830.64343-1-msc@linux.ibm.com> <87een93g2f.fsf@linux.ibm.com> User-Agent: Notmuch/0.29.1 (http://notmuchmail.org) Emacs/26.3 (x86_64-redhat-linux-gnu) Date: Thu, 10 Sep 2020 15:52:57 -0300 Message-ID: <877dt131me.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-10_08:2020-09-10, 2020-09-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 mlxscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100170 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Thu, 10 Sep 2020 18:53:04 -0000 Joseph Myers writes: > The first version is appropriate. The bigger limits for ibm128 are > deliberate. An architecture-specific ulps update should not be rejected > just because it increases ulps within the bounds accepted for that format > (and you shouldn't be able to get an update that increases them outside > those bounds unless you edit the ulps file manually, and if you do edit it > manually then the ulps it lists outside those bounds will be ignored > anyway). > > The most likely reason for rejecting an ulps update is that new ulps are > greater than for other architectures using the same code in glibc for the > same functions for the same format, suggesting that the update is actually > covering up a bug somewhere else. This doesn't apply in this case. > > (If an ulps increase results from a change to the implementation of a libm > functions that makes it less accurate in some cases, we need to consider > if we want that change, but that's deciding whether we want the libm > change, not deciding whether we want the ulps updates consequent on it.) Ack. Thanks for clarifying! Carlos O'Donell via Libc-alpha writes: > It was later shown to me that >9 ULPs was acceptable for ibm128, my apologies > for not being clearer that I was withdrawing my objection. Actually, I should be the one apologizing. > Patsy Griffin from my team also suggested this on September 2nd, she > is seeing these failures in our own testing. It would be good to have > them resolved. Especially after Patsy's message. > Before this patch, the following tests were failing: > > ppc and ppc64: > FAIL: math/test-ldouble-j0 > > ppc64le: > FAIL: math/test-float128-j0 > FAIL: math/test-float64x-j0 > FAIL: math/test-ibm128-j0 > FAIL: math/test-ldouble-j0 Tested and pushed as c71d13a0984f6. Thank you all!! -- Tulio Magno