From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59572 invoked by alias); 12 Dec 2016 16:43:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 59079 invoked by uid 89); 12 Dec 2016 16:43:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER autolearn=no version=3.3.2 spammy=186611, 18661-1, NaN, delivers X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed] To: libc-alpha@sourceware.org References: From: Stefan Liebler Date: Mon, 12 Dec 2016 16:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16121216-0036-0000-0000-000002757AA4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16121216-0037-0000-0000-00001399D805 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-12_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612120255 X-SW-Source: 2016-12/txt/msg00412.txt.bz2 On 12/03/2016 12:21 AM, Joseph Myers wrote: > Various pow function implementations mishandle sNaN arguments in > various ways. This includes returning sNaN instead of qNaN for sNaN > arguments. For arguments (1, sNaN) and (sNaN, 0), TS 18661-1 > semantics are also that the result should be qNaN, whereas with a qNaN > argument there the result should be 1, but for the dbl-64 > implementation of pow there are issues with sNaN arguments beyond not > implementing the TS 18661-1 semantics in those special cases. > > This patch makes the implementations in sysdeps/ieee754 follow the TS > 18661-1 semantics consistently. Because x86 / x86_64 implementations > still need fixing, testcases are not included with this patch; they > will be included with the fix for the x86 / x86_64 versions. > > Tested for x86_64, x86, mips64 and powerpc (with such testcases, which > pass in the mips64 and powerpc cases). Committed. Hi Joseph, on s390, I get test fails in math/test-double / math/test-idouble: testing double (without inline functions) Failure: Test: pow (1, sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow (1, -sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_downward (1, sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_downward (1, -sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_towardzero (1, sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_towardzero (1, -sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_upward (1, sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Failure: Test: pow_upward (1, -sNaN) Result: is: 1.0000000000000000e+00 0x1.0000000000000p+0 should be: qNaN Test suite completed: 97258 test cases plus 86314 tests for exception flags and 86314 tests for errno executed. 8 errors occurred. I've debugged in sysdeps/ieee754/dbl-64/e_pow.c and recognized that sNaN is converted to qNaN in line 85: if (y == 0) return 1.0; This comparison is done with a load-and-test instruction from and to the same register, which results in a qNaN. This value is passed to issignaling (y) in line 148: if (qy >= 0x7ff00000 && (qy > 0x7ff00000 || v.i[LOW_HALF] != 0)) /* NaN */ return x == 1.0 && !issignaling (y) ? 1.0 : y + y; From ieee 754-2008 "6.2 Operations with NaNs": "Under default exception handling, any operation signaling an invalid operation exception and for which a floating-point result is to be delivered shall deliver a quiet NaN." As the used load-and-test instruction delivers a result, I think qNaN is correct. But is the compiler allowed to use this instruction for a comparision against zero? How can I get rid of this issue? Shall I use "if ((v.i[HIGH_HALF] & 0x7fffffff) == 0x0)" on s390? Bye Stefan