From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27392 invoked by alias); 5 Sep 2008 22:39:15 -0000 Received: (qmail 27381 invoked by uid 22791); 5 Sep 2008 22:39: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; Fri, 05 Sep 2008 22:38:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 04AF62A970A; Fri, 5 Sep 2008 18:38:21 -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 TabhNl19qKWY; Fri, 5 Sep 2008 18:38:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C106B2A9705; Fri, 5 Sep 2008 18:38:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B9A08E7ACD; Sat, 6 Sep 2008 00:38:18 +0200 (CEST) Date: Fri, 05 Sep 2008 22:39:00 -0000 From: Joel Brobecker To: uweigand@de.ibm.com Cc: gdb-patches@sourceware.org Subject: Re: [rfc][10/37] Eliminate builtin_type_ macros: Use expression arch for argument promotion Message-ID: <20080905223818.GF15267@adacore.com> References: <20080831175045.128504000@de.ibm.com> <20080831175122.785640000@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080831175122.785640000@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/msg00113.txt.bz2 > This patch adds a number of _promote calls to ada-lang.c; while these > should simply preserve the status quo, someone familiar with the Ada > type promotion rules should probably have a look at those, maybe this > code can now be simplified a bit ... There are a few cases where I am also wondering whether a simplification might be possible or not (case UNOP_IN_RANGE, BINOP_IN_BOUNDS, TERNOP_IN_RANGE for instance), but I am not sure. I cannot test this patch and I won't be able to for at least a few more days or a week, so I'd say let's preserve the current status quo. -- Joel