From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20397 invoked by alias); 3 Apr 2013 15:41:57 -0000 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 Received: (qmail 20250 invoked by uid 89); 3 Apr 2013 15:41:53 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 03 Apr 2013 15:41:53 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UNPot-0004LB-IJ from joseph_myers@mentor.com ; Wed, 03 Apr 2013 08:41:51 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Apr 2013 08:41:51 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 3 Apr 2013 16:41:49 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UNPoq-0001RD-24; Wed, 03 Apr 2013 15:41:48 +0000 Date: Wed, 03 Apr 2013 15:41:00 -0000 From: "Joseph S. Myers" To: Thomas Schwinge CC: , Subject: Re: Policy question -- libm-test: tests with sNaNs as inputs In-Reply-To: <87ip43zl72.fsf@schwinge.name> Message-ID: References: <87ip43zl72.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-04/txt/msg00009.txt.bz2 On Wed, 3 Apr 2013, Thomas Schwinge wrote: > I'd like to propose the following patch, which adds several tests with > sNaNs as inputs to the libm-test framework. The tests for hypot are wrong - there, qNaN is considered to represent missing data, so hypot (qNaN, Inf) is Inf but hypot (sNaN, Inf) should be qNaN plus exception. Implementing this for hypot, fmin, fmax or complex functions would be a new feature rather than a simple bug fix, and I don't think you should add any tests for those functions, or comments about such tests being missing, unless you implement that new sNaN feature at the same time. > Now for the policy question: How to proceed in this case? Commit the My practice is to keep the testsuite clean on at least x86 and x86_64, by conditioning any new tests that fail on those architectures because of known bugs with a #if condition with a comment referencing the bug number (there are a few existing such comments in libm-test.inc). Other architecture maintainers may then fix the bugs for their architecture or add such conditionals in additional cases, depending on how difficult a fix is. -- Joseph S. Myers joseph@codesourcery.com