From patchwork Mon Mar 9 19:46:44 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella Netto X-Patchwork-Id: 5537 X-Patchwork-Delegate: azanella@linux.vnet.ibm.com Received: (qmail 17754 invoked by alias); 9 Mar 2015 19:46:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 17742 invoked by uid 89); 9 Mar 2015 19:46:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e24smtp04.br.ibm.com Message-ID: <54FDF8A4.5060100@linux.vnet.ibm.com> Date: Mon, 09 Mar 2015 16:46:44 -0300 From: Adhemerval Zanella User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Szabolcs Nagy CC: "GNU C. Library" Subject: Re: RFC: powerpc: Incorrect results for pow when using FMA References: <54FDF0E1.5090900@linux.vnet.ibm.com> <54FDF6AB.6030705@arm.com> In-Reply-To: <54FDF6AB.6030705@arm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15030919-0029-0000-0000-000002F76CEF On 09-03-2015 16:38, Szabolcs Nagy wrote: > > On 09/03/15 19:13, Adhemerval Zanella wrote: >> If I look at the comments at the top of the source file (sysdeps/ieee754/dbl-64/e_pow.c) >> where the power1() function lives, I see this comment: >> >> /* Assumption: Machine arithmetic operations are performed in */ >> /* round to nearest mode of IEEE 754 standard. */ >> >> It would seem to me that using FMAs would violate the assumption stated in that comment, >> since some of the internal FAM ops are not rounded before being used. I do notice that >> if I add the -ffp-contract=off, then we get the "expected" answer. Is the "correct" >> fix just to get this file compiled with -ffp-contract=off? >> > yes fma can break fp arithmetics that assume exact ieee semantics > > if compilers had proper iso c support then > > #pragma STDC FP_CONTRACT OFF > > in the affected functions would solve the problem > > (actually i'm not sure if it is supported now, but > i'd add the pragma anyway for documentation and > for future standard conforming compilers) > Right, but I think for GLIBC this is not usual way. I would suggest the followin fix: diff --git a/sysdeps/ieee754/dbl-64/Makefile b/sysdeps/ieee754/dbl-64/Makefile index 35f545f..5557c75 100644 --- a/sysdeps/ieee754/dbl-64/Makefile +++ b/sysdeps/ieee754/dbl-64/Makefile @@ -2,4 +2,5 @@ ifeq ($(subdir),math) # branred depends on precise IEEE double rounding CFLAGS-branred.c = $(config-cflags-nofma) CFLAGS-e_sqrt.c = $(config-cflags-nofma) +CFLAGS-e_pow.c = $(config-cflags-nofma) endif