From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25631 invoked by alias); 7 Sep 2008 16:44:40 -0000 Received: (qmail 25620 invoked by uid 22791); 7 Sep 2008 16:44:40 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 Sep 2008 16:43:57 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id m87GfoUU549500 for ; Sun, 7 Sep 2008 16:41:50 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 m87Gfo122752656 for ; Sun, 7 Sep 2008 18:41:50 +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 m87GfoUe023770 for ; Sun, 7 Sep 2008 18:41:50 +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 m87GfnFH023633; Sun, 7 Sep 2008 18:41:50 +0200 Message-Id: <200809071641.m87GfnFH023633@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 7 Sep 2008 18:41:16 +0200 Subject: Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers To: brobecker@adacore.com (Joel Brobecker) Date: Sun, 07 Sep 2008 16:44:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080906031428.GO15267@adacore.com> from "Joel Brobecker" at Sep 05, 2008 08:14:28 PM 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/msg00132.txt.bz2 Joel Brobecker wrote: > > @@ -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. OK, thanks for verifying this. > > 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... I agree that this should never trigger, as create_range_type is never called with a NULL index_type argument. (For stabsread.c it seems it might get called with a builtin_type_error argument in certain cases, but never NULL.) The same holds for the copies of this code in m2-typeprint.c and m2-valprint.c. However, I simply wanted to preserve the status quo with this patch set -- those checks can be removed with a follow-on patch. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com