From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63135 invoked by alias); 14 Dec 2016 09:54:16 -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 63102 invoked by uid 89); 14 Dec 2016 09:54:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*o:Research, H*MI:20161214095352, Our, act X-HELO: mx0a-001b2d01.pphosted.com Date: Wed, 14 Dec 2016 09:54:00 -0000 From: Andreas Krebbel To: Joseph Myers Cc: libc-alpha@sourceware.org, stli@linux.vnet.ibm.com Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed] References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16121409-0016-0000-0000-0000027F9890 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16121409-0017-0000-0000-0000242FBD61 Message-Id: <20161214095352.GA17128@maggie> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-14_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612140170 X-SW-Source: 2016-12/txt/msg00490.txt.bz2 On Tue, Dec 13, 2016 at 09:42:14PM +0000, Joseph Myers wrote: > On Mon, 12 Dec 2016, Stefan Liebler wrote: > > > 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? > > TS 18661-1 allows for floating-point assignments and argument passing > (etc.) to act as convertFormat operations, so converting signaling NaNs to > quiet. > > Obviously when implemented that way, issignaling cannot work reliably. As > a quality-of-implementation issue it's probably best to avoid such > instructions for simple loads of stored values, at least when > -fsignaling-nans is in use. > > So if -fsignaling-nans avoids the issue, compiling pow with > -fsignaling-nans on s390 would make sense (most of libm isn't built with > -fsignaling-nans and should still work fine). Otherwise the tests of > sNaNs can be disabled in a math-tests.h file for your architecture (like > sysdeps/i386/fpu/math-tests.h), which should have a comment pointing to a > bug report in GCC Bugzilla about the issue. The problem with the load and test instruction is that it is not consistent to doing a load and a compare separately. Our floating point loads do not quiet a NaN. While the IEEE standard leaves it open to quiet NaNs with loads it is probably supposed to be the same for all loads. The plan is to disable the use of the FPR result of a load-and-test instruction in the compiler. We would leave the Glibc tests failing since this appears to be a real finding to me. Does this sound reasonable? -Andreas-