From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24342 invoked by alias); 29 Jan 2008 15:48:26 -0000 Received: (qmail 24333 invoked by uid 22791); 29 Jan 2008 15:48:25 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 15:48:04 +0000 Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id m0TFm1XG029203 for ; Tue, 29 Jan 2008 07:48:01 -0800 Received: from rv-out-0910.google.com (rvbk20.prod.google.com [10.140.87.20]) by zps76.corp.google.com with ESMTP id m0TFm1OI024008 for ; Tue, 29 Jan 2008 07:48:01 -0800 Received: by rv-out-0910.google.com with SMTP id k20so1799684rvb.3 for ; Tue, 29 Jan 2008 07:48:00 -0800 (PST) Received: by 10.140.142.4 with SMTP id p4mr4239487rvd.261.1201621680625; Tue, 29 Jan 2008 07:48:00 -0800 (PST) Received: by 10.141.186.16 with HTTP; Tue, 29 Jan 2008 07:48:00 -0800 (PST) Message-ID: Date: Tue, 29 Jan 2008 15:51:00 -0000 From: "Doug Evans" To: "Joel Brobecker" Subject: Re: [BUG] BINOP_DIV and ptyp command Cc: "GDB Patches" , "Pierre Muller" In-Reply-To: <20080129064148.GB16288@adacore.com> 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> <20080129064148.GB16288@adacore.com> 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/msg00679.txt.bz2 On Jan 28, 2008 10:41 PM, Joel Brobecker wrote: > > I may be missing something, but it seems like special casing > > EVAL_AVOID_SIDE_EFFECTS for DIV/MOD/REM is no longer useful here > > I don't think this is right. EVAL_AVOID_SIDE_EFFECTS is used when > computing the actual value is not needed. For instance, when you do > "ptype", the expression is evaluated in that mode. So when you do > "ptype 3 div 2", we don't do the division, we just know that we're only > interested in the type of result. So the expression evaluator will > return a struct value of the correct type but with a bogus contents, > instead of doing the division, only to discard the result down the road. > > So the code you suggested we remove is useful. As I say, if the intent is to avoid the call to error(), I'd expect to see tests for 1 >> 3.0, etc. That will throw error ("Integer-only operation on floating point number"). If that code is the code that's missing, fine, except that I'd also change the comments describing what EVAL_AVOID_SIDE_EFFECTS is for: EVAL_AVOID_SIDE_EFFECTS /* Don't modify any variables or call any functions. The value returned will have the correct type, and will have an approximately correct lvalue type (inaccuracy: anything that is listed as being in a register in the function in which it was declared will be lval_register). */ One can believe the intent that side effects in this particular case includes throwing error(), but the docs should be explicit on this.