From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16992 invoked by alias); 29 Jan 2008 04:53:55 -0000 Received: (qmail 16981 invoked by uid 22791); 29 Jan 2008 04:53:54 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 04:53:34 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m0T4quop001045 for ; Tue, 29 Jan 2008 04:52:57 GMT Received: from rv-out-0910.google.com (rvbl15.prod.google.com [10.140.88.15]) by zps36.corp.google.com with ESMTP id m0T4qtUM025426 for ; Mon, 28 Jan 2008 20:52:56 -0800 Received: by rv-out-0910.google.com with SMTP id l15so1869018rvb.43 for ; Mon, 28 Jan 2008 20:52:55 -0800 (PST) Received: by 10.141.20.7 with SMTP id x7mr4056450rvi.183.1201582375346; Mon, 28 Jan 2008 20:52:55 -0800 (PST) Received: by 10.141.186.16 with HTTP; Mon, 28 Jan 2008 20:52:55 -0800 (PST) Message-ID: Date: Tue, 29 Jan 2008 05:26:00 -0000 From: "Doug Evans" To: "GDB Patches" Subject: Re: [BUG] BINOP_DIV and ptyp command Cc: "Pierre Muller" In-Reply-To: <002301c85c12$a73a4640$f5aed2c0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002301c85c12$a73a4640$f5aed2c0$@u-strasbg.fr> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00665.txt.bz2 On Jan 21, 2008 1:47 AM, Pierre Muller wrote: > The ptyp command returns inconsistent types for the c '/'(BINOP_DIV) > operator: > > (gdb) ptyp 3 / 2 > type = int > (gdb) p 3 / 2 > $4 = 1 > (gdb) ptyp 3.0 / 2 > type = double > (gdb) p 3.0 / 2 > $5 = 1.5 > (gdb) ptyp 3 / 2.0 > type = int > (gdb) p 3 / 2.0 > $6 = 1.5 > > I suspect that this bug is due to the fact that > the type of this binary operator is inferred from the > left node type, but this is wrong in the case '3 / 2.0' > > > Pierre Muller I may be missing something, but it seems like special casing EVAL_AVOID_SIDE_EFFECTS for DIV/MOD/REM is no longer useful here (one can imagine that it was added way back when to avoid division by zero, but I'm just guessing). I don't see any need to special case this here, value_binop will catch integer division by zero and doesn't have any special checks for floating point division by 0 (uses host fp which can result in +/-inf, and isn't necessarily accurate for the target at any rate, but that's an orthogonal issue). If it were a case of wanting to avoid tripping over the call to error("Division by zero") then I'd expect to also see special casing of "1 >> 3.0" when EVAL_AVOID_SIDE_EFFECTS. Also note that for integer MOD, "division by zero" isn't an issue. So it seems like the following is the correct patch. 2008-01-28 Doug Evans * eval.c (evaluate_subexp_standard): If DIV/REM/MOD and EVAL_AVOID_SIDE_EFFECTS, remove special case and process normally. Index: eval.c =================================================================== RCS file: /cvs/src/src/gdb/eval.c,v retrieving revision 1.77 diff -u -p -u -p -r1.77 eval.c --- eval.c 18 Jan 2008 17:07:39 -0000 1.77 +++ eval.c 29 Jan 2008 04:37:52 -0000 @@ -1509,9 +1509,6 @@ evaluate_subexp_standard (struct type *e goto nosideret; if (binop_user_defined_p (op, arg1, arg2)) return value_x_binop (arg1, arg2, op, OP_NULL, noside); - else if (noside == EVAL_AVOID_SIDE_EFFECTS - && (op == BINOP_DIV || op == BINOP_REM || op == BINOP_MOD)) - return value_zero (value_type (arg1), not_lval); else return value_binop (arg1, arg2, op);