From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8845 invoked by alias); 3 May 2005 14:16:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8762 invoked from network); 3 May 2005 14:16:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 May 2005 14:16:27 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j43EGQBg004289; Tue, 3 May 2005 10:16:26 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j43EGQO29953; Tue, 3 May 2005 10:16:26 -0400 Received: from topo.toronto.redhat.com (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j43EGNxY025402; Tue, 3 May 2005 10:16:25 -0400 Received: from topo.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by topo.toronto.redhat.com (8.13.1/8.12.11) with ESMTP id j43EGDRn021406; Tue, 3 May 2005 10:16:14 -0400 Received: (from dnovillo@localhost) by topo.toronto.redhat.com (8.13.1/8.13.1/Submit) id j43EGDgi021405; Tue, 3 May 2005 10:16:13 -0400 Date: Tue, 03 May 2005 14:16:00 -0000 From: Diego Novillo To: Richard Kenner Cc: gcc@gcc.gnu.org Subject: Re: Q about Ada and value ranges in types Message-ID: <20050503141613.GA21050@topo.toronto.redhat.com> References: <10505030146.AA26099@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <10505030146.AA26099@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-05/txt/msg00080.txt.bz2 On Mon, May 02, 2005 at 09:46:59PM -0400, Richard Kenner wrote: > You're not showing where this comes from, so it's hard to say. However > D.1480 is created by the gimplifier, not the Ada front end. There could > easily be a typing problem in the tree there (e.g., that of the subtraction), > but I can't tell for sure. > Yeah, I didn't show all of it, sorry. My patch to address this problem includes a more detailed description (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html). Florian Weimer suggested that instead of marking the range as varying, we could check the super-type to see if it has a wider range. That is true in this case; the parent type is types__Tname_idB which has range [-2147483648, 2147483647]. But I'm not sure if that would be true in general. > If the Ada language allows that kind of runtime check, then my > fix to VRP will be different. > > I don't see it as a language issue: I'd argue that the tree in statement 2 > is invalid given the typing. That should be true for any language. > Dunno. All the operands in the snippet I showed are of the exact same type (types__name_id___XDLU_300000000__399999999). I'm not really sure where this type is coming from, but it's relatively easy to reproduce. Configure a compiler for target i386-pc-linux-gnu (or any other i386 variant, not sure if it occurs elsewhere) and compile ada/sem_intr.adb with: $ ./xgcc -B./ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/gcc/ada /gcc/ada/sem_intr.adb -o ada/sem_intr.o -v -save-temps Launch gdb and set a bkpt at tree-vrp.c:552 (extract_range_from_assert). You should get to this ASSERT_EXPR: ASSERT_EXPR which is in the following context: ----------------------------------------------------------------------------- ;; basic block 44, loop depth 0, count 0 ;; prev block 43, next block 84 ;; pred: 43 (true,exec) ;; succ: 84 (true,exec) 45 (false,exec) :; D.1478_28 = sinfo__etype (e_5); nam_30 = sinfo__chars (e_5); D.1480_32 = nam_30 - 300000361; if (D.1480_32 <= 1) goto ; else goto ; ;; basic block 84, loop depth 0, count 0 ;; prev block 44, next block 45 ;; pred: 44 (true,exec) ;; succ: 50 [100.0%] (fallthru) :; D.1480_94 = ASSERT_EXPR ; goto (); ----------------------------------------------------------------------------- So, after calling sinfo__chars() and subtracting 300000361, the FE is emitting that range check. AFAICT, the call to sinfo__chars(e_5) comes from ada/sem_intr.adb:148 Nam : constant Name_Id := Chars (E); and 'if (D.1480_32 <= 1)' is at line 155: if Nam = Name_Op_Add Thanks. Diego.