From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-53653-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 26614 invoked by alias); 29 Jan 2008 16:25:21 -0000
Received: (qmail 26568 invoked by uid 22791); 29 Jan 2008 16:25:20 -0000
X-Spam-Check-By: sourceware.org
Received: from ics.u-strasbg.fr (HELO ics.u-strasbg.fr) (130.79.112.250)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 16:24:57 +0000
Received: from ICSMULLER (laocoon.u-strasbg.fr [130.79.112.72]) 	by ics.u-strasbg.fr (Postfix) with ESMTP id 362E618701F; 	Tue, 29 Jan 2008 17:31:18 +0100 (CET)
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Doug Evans'" <dje@google.com>
Cc: "'Joel Brobecker'" <brobecker@adacore.com>, 	"'GDB Patches'" <gdb-patches@sourceware.org>
References: <002301c85c12$a73a4640$f5aed2c0$@u-strasbg.fr>	 <e394668d0801282052g3c3b0510l3448f39a5a6d78f0@mail.gmail.com>	 <20080129064148.GB16288@adacore.com>	 <000e01c86249$89870100$9c950300$@u-strasbg.fr> <e394668d0801290751s7e68fddasa300e612ad6f421e@mail.gmail.com>
In-Reply-To: <e394668d0801290751s7e68fddasa300e612ad6f421e@mail.gmail.com>
Subject: RE: [BUG] BINOP_DIV and ptyp command
Date: Tue, 29 Jan 2008 16:34:00 -0000
Message-ID: <001801c86293$7c116b10$74344130$@u-strasbg.fr>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2008-01/txt/msg00685.txt.bz2

Doug, I tend to agree with you that
we should always call value_binop,
or never, not on all cases
except BINOP_DIV, BINOP_INTDIV, BINOP_REM and BINOP_MOD
this is not logical as you explained it.

 The current code makes
those operators listed above act 
differently from other operators for 'ptype' command
and lead to several cases where
(gdb) print EXPR
$? = EXPRESULT
(gdb) ptype $
returns another type than
(gdb) ptype EXPR

  The implicit conversion rules in
value_binop are rather complicated...

Try for instance

(gdb) ptyp 1.5 * 2.5l
type = long double
but 
(top-gdb) p 1.5 / 2.5l
$1 = 0.60000000000000000002168404344971009
(top-gdb) ptyp $
type = long double
(top-gdb) ptyp 1.5 / 2.5l
type = double

But anyhow,
(gdb) ptyp 1 * 2.5
type = double
but 
(top-gdb) p 1 / 2.5
$1 = 0.40000000000000000002
(top-gdb) ptyp $
type = double
(top-gdb) ptyp 1 / 2.5
type = int 
Is obviously a much bigger bug, no?

I don't care much about 'int' 'long int' or 'long long int'
but 'int' and 'double' are completely different story!

Pierre