From owner-freebsd-alpha@FreeBSD.ORG Sat Oct 9 23:10:21 2004 Return-Path: Delivered-To: freebsd-alpha@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D13F816A4CE for ; Sat, 9 Oct 2004 23:10:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A47DD43D1F for ; Sat, 9 Oct 2004 23:10:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i99NALoP078479 for ; Sat, 9 Oct 2004 23:10:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i99NAL6r078478; Sat, 9 Oct 2004 23:10:21 GMT (envelope-from gnats) Date: Sat, 9 Oct 2004 23:10:21 GMT Message-Id: <200410092310.i99NAL6r078478@freefall.freebsd.org> To: freebsd-alpha@FreeBSD.org From: Peter Edwards Subject: Re: alpha/72024: LONG_MIN / 1 sends a "Floating exception" X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2004 23:10:21 -0000 The following reply was made to PR alpha/72024; it has been noted by GNATS. From: Peter Edwards To: freebsd-gnats-submit@FreeBSD.org, ppelissi@caramail.com Cc: Subject: Re: alpha/72024: LONG_MIN / 1 sends a "Floating exception" Date: Sun, 10 Oct 2004 00:03:13 +0100 This is a multi-part message in MIME format. --------------020907060008000208010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ooh a good excuse to look at Alpha assembler. (/me googles for the alpha instruction set.) (Can someone on the -alpha list tell me if this reasoning is correct, and if I should commit the patch?) Alpha appears not to have an integer division instruction, so this is implemented by divq(), the source of which is generated from "src/lib/libc/alpha/gen/divrem4" (For reading the macros when preprocessing as divq, S is true, OP is "div", and WORDSIZE is 64) If I'm reading it correctly, the start of this function decides what sign the result should have, then gets the absolute value of each operand, (search for "subq zero, A, A" and "subq zero, B, B".) Note, for "LONG_MIN", or 0x8000000000000000, 2's compliment subtraction for zero gives back the 0x8000000000000000 The body of the work is done with logical shifts, so everything still works when treating the dividend as an unsigned long. At the end of the function, the code takes the calculated result, and decides if it needs to negate it: > /* Check to see if we should negate it. */ > subqv zero, RESULT, T_0 > cmovlbs NEG, T_0, RESULT The "v" here means "trap overflows", which is why we blow up. LONG_MIN is the only value that _can_ blow up here, and you can only reach this case if you start with LONG_MIN / 1, if my reasoning isn't flawed. So, I think it's perfectly safe to remove the "v" from the subq instruction. i.e., I think the attached patch is correct. --------------020907060008000208010003 Content-Type: text/plain; name="divrem.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="divrem.txt" Index: lib/libc/alpha/gen/divrem.m4 =================================================================== RCS file: /usr/cvs/FreeBSD-CVS/src/lib/libc/alpha/gen/divrem.m4,v retrieving revision 1.3 diff -u -r1.3 divrem.m4 --- lib/libc/alpha/gen/divrem.m4 10 May 2000 19:04:57 -0000 1.3 +++ lib/libc/alpha/gen/divrem.m4 9 Oct 2004 22:54:36 -0000 @@ -172,7 +172,7 @@ ifelse(S, `true', ` /* Check to see if we should negate it. */ - subqv zero, RESULT, T_0 + subq zero, RESULT, T_0 cmovlbs NEG, T_0, RESULT ') --------------020907060008000208010003--