From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2931 invoked by alias); 30 Jul 2004 13:18:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 2890 invoked from network); 30 Jul 2004 13:18:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 30 Jul 2004 13:18:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6UDIGe1022114; Fri, 30 Jul 2004 09:18:16 -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 i6UDIFa30176; Fri, 30 Jul 2004 09:18:15 -0400 Received: from [127.0.0.1] (vpn50-6.rdu.redhat.com [172.16.50.6]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i6UDIDXP025741; Fri, 30 Jul 2004 09:18:14 -0400 Subject: Re: Fix processing of ADDR_EXPR in get_expr_operands From: Diego Novillo To: Richard Kenner Cc: "gcc-patches@gcc.gnu.org" In-Reply-To: <10407300327.AA14969@vlsi1.ultra.nyu.edu> References: <10407300327.AA14969@vlsi1.ultra.nyu.edu> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1091193498.5942.215.camel@localhost.localdomain> Mime-Version: 1.0 Date: Fri, 30 Jul 2004 19:05:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg02696.txt.bz2 On Thu, 2004-07-29 at 23:27, Richard Kenner wrote: > I don't know *why* ADDR_EXPR of a volatile is not TREE_CONSTANT. I > don't really care. > > Well, I do. It sounds like a bug to me. Indeed it sounds like the central > bug in what you're trying to fix. > No. It is not a bug. I don't know how else to tell you the same thing. Address constness is checked with TREE_INVARIANT. The address of a variable may be invariant in one invocation to a function, but have different values from call to call. > All I know, and always use, is that constness of ADDR_EXPRs is tested > with TREE_INVARIANT. Hence the call to is_gimple_min_invariant. Even > TREE_CONSTANT is not always right, you have to check for overflow as > well. > > Overflow? > Yes. Overflow. > Which you will notice sets both TREE_CONSTANT and TREE_INVARIANT, not > necessarily with the same value. > > Right, I know it does. Indeed I made some changes to that code. > Then why are we having this conversation? You should know why we set TREE_INVARIANT instead of TREE_CONSTANT, then. Diego.