From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12162 invoked by alias); 9 Sep 2008 20:21:20 -0000 Received: (qmail 12125 invoked by uid 22791); 9 Sep 2008 20:21:17 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Sep 2008 20:18:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m89KGqxO403834 for ; Tue, 9 Sep 2008 20:16:52 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m89KGqmc4321406 for ; Tue, 9 Sep 2008 22:16:52 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m89KGp9I024086 for ; Tue, 9 Sep 2008 22:16:51 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m89KGp49023924; Tue, 9 Sep 2008 22:16:51 +0200 Message-Id: <200809092016.m89KGp49023924@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 9 Sep 2008 22:16:38 +0200 Subject: Re: [rfc][19/37] Eliminate builtin_type_ macros: Ada range type handling To: brobecker@adacore.com (Joel Brobecker) Date: Tue, 09 Sep 2008 20:21:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080909175934.GE12222@adacore.com> from "Joel Brobecker" at Sep 09, 2008 10:59:34 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-09/txt/msg00195.txt.bz2 Joel Brobecker wrote: > So, for ada_array_length, shall use use a type of builtin_type_int32? > That's what I did for my testing (more on this in a separate message) OK, I've changed the patch accordingly. > > > > case TYPE_CODE_RANGE: > > > > - arg2 = value_from_longest (builtin_type_int, TYPE_LOW_BOUND (type)); > > > > - arg3 = value_from_longest (builtin_type_int, > > > > - TYPE_HIGH_BOUND (type)); > > > > + arg2 = value_from_longest (TYPE_TARGET_TYPE (type), > > > > + TYPE_LOW_BOUND (type)); > > > > + arg3 = value_from_longest (TYPE_TARGET_TYPE (type), > > > > + TYPE_HIGH_BOUND (type)); > > > > binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); > > > > binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg3); > > > > type = language_bool_type (exp->language_defn, exp->gdbarch); > > > > > > I don't really understand why the TYPE_TARGET_TYPE is necessarily > > > an integer type. I don't even think that the TYPE_TARGET_TYPE > > > is necessarily set, particularly in the case of enumerated types > > > or base types. > > > > > > We have access to the int type through the expression in this case. > > > Can we use that? > > > > I guess so, but it would appear this doesn't really help. There isn't > > really anything in the language that says the gdbarch's int type is the > > "correct" type to use here, or is there? > > No, I don't think so. I had a look at the Ada Reference Manual, > and it doesn't say anything about that. > > > If not, and this is just about using some "random" integer type to perform > > the comparison in, it seems to me using builtin_type_int32 here as well > > would be better ... > > It just occured to me that, since this is a TYPE_CODE_RANGE, can't > we just use its type? A TYPE_CODE_RANGE should always be some kind > of "integer" type, so why not use that when calling value_from_longest? > I have this awful feeling that we're missing something, but I don't > see what. Do you see anything wrong with that? Well, the only effect going through GDB values to perform the comparison has is to do the appropriate type promotions. However, if this doesn't actually apply for Ada, I'm wondering why we don't simply do the comparison on integral LONGEST values directly, like in the patch below? Does this make sense? Bye, Ulrich ChangeLog: * ada-lang.c (ada_array_length): Use builtin_type_int32 instead of builtin_type_int. (ada_evaluate_subexp): Perform range check on LONGEST values instead of on GDB values. Index: gdb-head/gdb/ada-lang.c =================================================================== --- gdb-head.orig/gdb/ada-lang.c +++ gdb-head/gdb/ada-lang.c @@ -2623,7 +2623,7 @@ ada_array_length (struct value *arr, int } else return - value_from_longest (builtin_type_int, + value_from_longest (builtin_type_int32, value_as_long (desc_one_bound (desc_bounds (arr), n, 1)) - value_as_long (desc_one_bound (desc_bounds (arr), @@ -8860,18 +8860,13 @@ ada_evaluate_subexp (struct type *expect return value_from_longest (type, (LONGEST) 1); case TYPE_CODE_RANGE: - arg2 = value_from_longest (builtin_type_int, TYPE_LOW_BOUND (type)); - arg3 = value_from_longest (builtin_type_int, - TYPE_HIGH_BOUND (type)); - binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); - binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg3); - type = language_bool_type (exp->language_defn, exp->gdbarch); - return - value_from_longest (type, - (value_less (arg1, arg3) - || value_equal (arg1, arg3)) - && (value_less (arg2, arg1) - || value_equal (arg2, arg1))); + { + LONGEST val = value_as_long (arg1); + LONGEST low = TYPE_LOW_BOUND (type); + LONGEST high = TYPE_HIGH_BOUND (type); + type = language_bool_type (exp->language_defn, exp->gdbarch); + return value_from_longest (type, low <= val && val <= high); + } } case BINOP_IN_BOUNDS: -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com