From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1621 invoked by alias); 6 Sep 2008 03:15:32 -0000 Received: (qmail 1606 invoked by uid 22791); 6 Sep 2008 03:15:29 -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; Sat, 06 Sep 2008 03:14:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 52B7E2A9683; Fri, 5 Sep 2008 23:14:31 -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 6pfucAnlX4et; Fri, 5 Sep 2008 23:14:31 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F26132A967D; Fri, 5 Sep 2008 23:14:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 00184E7ACD; Sat, 6 Sep 2008 05:14:28 +0200 (CEST) Date: Sat, 06 Sep 2008 03:15:00 -0000 From: Joel Brobecker To: uweigand@de.ibm.com Cc: gdb-patches@sourceware.org Subject: Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers Message-ID: <20080906031428.GO15267@adacore.com> References: <20080831175045.128504000@de.ibm.com> <20080831175132.651479000@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080831175132.651479000@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/msg00122.txt.bz2 > @@ -197,11 +197,11 @@ print_range_bound (struct type *type, ch > the upper bound of the 0 .. -1 range types to be printed as > a very large unsigned number instead of -1. > To workaround this stabs deficiency, we replace the TYPE by > - builtin_type_long when we detect that the bound is negative, > + builtin_type_int32 when we detect that the bound is negative, > and the type is a TYPE_CODE_INT. The bound is negative when > 'm' is the last character of the number scanned in BOUNDS. */ > if (bounds[*n - 1] == 'm' && TYPE_CODE (type) == TYPE_CODE_INT) > - type = builtin_type_long; > + type = builtin_type_int32; > ada_print_scalar (type, B, stream); > if (bounds[*n] == '_') > *n += 2; I'm slightly concerned about the effect of this change on 64-bit platforms. Normally, stabs is a 32bit format so this shouldn't be a problem, but Tru64 is a 64-bit platform with stabs, and the range values are stored as text in the stabs string. So presumably 64-bit range types are possible... However, I couldn't come up with a case where things get degraded. Nor did the testsuite, which does also test the case described in the comments), reveal any regression. So I guess we should be OK. > Index: gdb-head/gdb/p-typeprint.c > =================================================================== > --- gdb-head.orig/gdb/p-typeprint.c > +++ gdb-head/gdb/p-typeprint.c > @@ -756,7 +756,7 @@ pascal_type_print_base (struct type *typ > { > struct type *target = TYPE_TARGET_TYPE (type); > if (target == NULL) > - target = builtin_type_long; > + target = builtin_type_int32; > print_type_scalar (target, TYPE_LOW_BOUND (type), stream); > fputs_filtered ("..", stream); > print_type_scalar (target, TYPE_HIGH_BOUND (type), stream); Just an observation: This part seems erroneous, no? type is a TYPE_CODE_RANGE, but there is no underlying TARGET_TYPE? Would it make better sense to error-out instead? On platforms using DWARF, this should never happen (we complain about the missing base type and use an integer type as a substitute). For stabs, things seem a little less clear, but it looks like we also always create range types with a base type. So maybe this should never happen. Anyway, if there is a Fortran maintainer reading this... -- Joel