From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93109 invoked by alias); 13 Dec 2016 21:42:35 -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 93089 invoked by uid 89); 13 Dec 2016 21:42:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=delivers, sk:quality, H*M:20484, act X-HELO: relay1.mentorg.com Date: Tue, 13 Dec 2016 21:42:00 -0000 From: Joseph Myers To: Stefan Liebler CC: Subject: Re: Fix sysdeps/ieee754 pow handling of sNaN arguments (bug 20916) [committed] In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-12/txt/msg00480.txt.bz2 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. -- Joseph S. Myers joseph@codesourcery.com