From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26948 invoked by alias); 9 Sep 2008 18:00:16 -0000 Received: (qmail 26927 invoked by uid 22791); 9 Sep 2008 18:00:14 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Sep 2008 17:59:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 224912A96A5; Tue, 9 Sep 2008 13:59:37 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kHL1yNHlXSDl; Tue, 9 Sep 2008 13:59:37 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B74DF2A9698; Tue, 9 Sep 2008 13:59:36 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 45F7FE7ACD; Tue, 9 Sep 2008 19:59:34 +0200 (CEST) Date: Tue, 09 Sep 2008 18:00:00 -0000 From: Joel Brobecker To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc][19/37] Eliminate builtin_type_ macros: Ada range type handling Message-ID: <20080909175934.GE12222@adacore.com> References: <20080906002342.GJ15267@adacore.com> <200809071542.m87FgUGp031738@d12av02.megacenter.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809071542.m87FgUGp031738@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.4.2.2i 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/msg00191.txt.bz2 > > > two more small changes to ada-lang.c: ada_array_length would > > > simply use builtin_type_int as type of its return value, even > > > though it should probably better use the type of the array bounds. > > > > I don't think this part is correct, since the bounds can be any discrete > > type, which includes enumeration types. The 'Length attribute is defined > > as returning a universal_integer. The definition of universal_integer > > is a little complicated for me, but it is an integer. > > I see; it seems I have misinterpreted range types -- I though they > were always based on an integer type. A range type is, I think, always based on an integer type. But the thing is that array index types can be any discrete type: This means that one can use an enumerated type as well. 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) > > > 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? -- Joel