From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12206 invoked by alias); 7 Nov 2012 13:09:26 -0000 Received: (qmail 12195 invoked by uid 22791); 7 Nov 2012 13:09:25 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,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, 07 Nov 2012 13:09:15 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TW5Nb-0001Rb-69 from joseph_myers@mentor.com ; Wed, 07 Nov 2012 05:09:15 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 05:09:14 -0800 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, 7 Nov 2012 13:09:13 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1TW5NY-0000NV-FW; Wed, 07 Nov 2012 13:09:12 +0000 Date: Wed, 07 Nov 2012 13:09:00 -0000 From: "Joseph S. Myers" To: Marcus Shawcroft CC: Subject: Re: [PATCH 1/2] AArch64 glibc port In-Reply-To: Message-ID: References: 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-11/txt/msg00026.txt.bz2 On Wed, 7 Nov 2012, Marcus Shawcroft wrote: > This resolves the majority of the outstanding issues. The solution > above is not quite sufficient because given a true 0, FP_ROUND may set > working bits resulting in the underflow test failing. I resolved this > by adjusting FP_ROUND such that it does not attempt to round a true > zero, is that sane? I've attached my current patch. The patch is I think it would be better to put all the rounding logic inside the existing "if (_FP_FRAC_LOW_##wc(X) & 7)" conditional that determines whether to set the INEXACT exception - if none of the low three bits is set, there's no point in doing anything for rounding. soft-fp patches should go to libc-alpha. (Once checked in, the patch to update all the soft-fp files in libgcc from their soft-fp versions goes to gcc-patches, of course.) > against glibc/soft-fp but I've actually be using it applied to > libgcc/soft-fp. What is the recommend way to test patches to soft-fp > in glibc? You could ask the architecture maintainer of an architecture that uses soft-fp in glibc (e.g. SPARC) to test it, though I think testing in libgcc is just as useful. -- Joseph S. Myers joseph@codesourcery.com