From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29873 invoked by alias); 5 Nov 2012 18:06:15 -0000 Received: (qmail 29856 invoked by uid 22791); 5 Nov 2012 18:06:13 -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; Mon, 05 Nov 2012 18:06:08 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TVR3m-0002hf-Lu from joseph_myers@mentor.com ; Mon, 05 Nov 2012 10:06:06 -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); Mon, 5 Nov 2012 10:06:05 -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; Mon, 5 Nov 2012 18:06:05 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1TVR3j-0006NX-U4; Mon, 05 Nov 2012 18:06:03 +0000 Date: Mon, 05 Nov 2012 18:06: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/msg00019.txt.bz2 On Mon, 5 Nov 2012, Marcus Shawcroft wrote: > Digging into the behaviour of trunctfdf2 (provided by libgcc) on the > value LDBL_MIN, I expected to see INEXACT and UNDERFLOW but only get > INEXACT. I'm looking at the current soft-fp code in glibc rather than the older version in libgcc (which will need updating from glibc once this issue is resolved [*]) but don't see any relevant differences. There are two places in op-common.h handling underflow, _FP_PACK_SEMIRAW and _FP_PACK_CANONICAL. Looking first at the latter (not the one involved in the present issue), it seems OK on the basis of tininess-before-rounding. (Tininess-after-rounding would need extra work. 32-bit ARM is tininess-before-rounding, so I'll guess that AArch64 is as well.) That is, it will raise the underflow flag for all inexact underflow cases, including underflow to zero. For the former, there are two issues with the underflow handling: it's determined based on the exponent after rounding (which is not correct for either "before rounding" or "after rounding" tininess detection - "after rounding" tininess detection means after rounding to the normal precision rather than after rounding to an actual representable value), and it has the test you note for whether the mantissa, after shifting, is nonzero. I think the correct thing to do would be to have a test "if (X##_e == 0 && !_FP_FRAC_ZEROP_##wc(X))" (which then has the existing exception-setting logic) immediately after the _FP_ROUND call. That way, (a) the logic is before-rounding tininess, which at least is consistent with _FP_PACK_CANONICAL, (b) the INEXACT exception has been set by _FP_ROUND if applicable, as required for the logic determining whether to raise the underflow flag and (c) the low bits haven't yet been shifted out, so an exact zero can be distinguished from an inexact one by the mantissa. The code that now has "if (!_FP_EXP_NORMAL(fs, wc, X) && !_FP_FRAC_ZEROP_##wc(X))" might then better test "(X##_e == _FP_EXPMAX_##fs && !_FP_FRAC_ZEROP_##wc(X))" (i.e., the value is a NaN, the only remaining case there). After-rounding tininess detection would be more complicated, but as I note above it's probably irrelevant to AArch64 (though relevant to complete correctness for Alpha and MIPS, and for the use of soft-fp for __float128 in libgcc for x86 / x86_64 / IA64). [*] See what I said in regarding asking architecture maintainers to help provide FP_TRAPPING_EXCEPTIONS definitions after such an update. -- Joseph S. Myers joseph@codesourcery.com