From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20548 invoked by alias); 30 May 2012 23:51:33 -0000 Received: (qmail 20540 invoked by uid 22791); 30 May 2012 23:51:32 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 May 2012 23:51:20 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SZsff-0000AC-Bs from joseph_myers@mentor.com ; Wed, 30 May 2012 16:51:19 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2012 00:51:17 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1SZsfc-0004ru-JJ; Wed, 30 May 2012 23:51:16 +0000 Date: Wed, 30 May 2012 23:51:00 -0000 From: "Joseph S. Myers" To: rth@twiddle.net cc: libc-ports@sourceware.org Subject: fma ulps In-Reply-To: <20120530233749.16824.qmail@sourceware.org> Message-ID: References: <20120530233749.16824.qmail@sourceware.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00205.txt.bz2 On Wed, 30 May 2012, rth@sourceware.org wrote: > +# fma > +Test "fma (-0x1.19cab66d73e17p-959, 0x1.c7108a8c5ff51p-107, -0x0.80b0ad65d9b64p-1022) == -0x0.80b0ad65d9d59p-1022": > +double: 1 > +idouble: 1 > +Test "fma (0x1.0000002p+0, 0x1.ffffffcp-1, -0x1p-300) == 0x1.fffffffffffffp-1": > +double: 1 > +idouble: 1 > +Test "fma (0x1.153d650bb9f06p-907, 0x1.2d01230d48407p-125, -0x0.b278d5acfc3cp-1022) == -0x0.b22757123bbe9p-1022": > +double: 1 > +idouble: 1 > +Test "fma (0x1.4000004p-967, 0x1p-106, 0x0.000001p-1022) == 0x0.0000010000003p-1022": > +double: 1 > +idouble: 1 fma isn't meant to have ulps. You previously mentioned that special options are needed to get "inexact" exceptions on alpha, and the fma code relies on testing those exceptions to get correct results, so maybe you need to make appropriate arrangements for it (for all floating-point types) to be compiled with the right options to get such exceptions? (I cut out fma ulps from my ARM results, pending testing on hardware to see if they were a QEMU bug or something needing further investigation.) -- Joseph S. Myers joseph@codesourcery.com