From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24500 invoked by alias); 18 Oct 2004 19:54:13 -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 24486 invoked from network); 18 Oct 2004 19:54:13 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 18 Oct 2004 19:54:13 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA07594; Mon, 18 Oct 04 15:58:01 EDT Date: Mon, 18 Oct 2004 19:57:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10410181958.AA07594@vlsi1.ultra.nyu.edu> To: jason@redhat.com Subject: Re: [PATCH] fix PR middle-end/17885, gimplifing of volatile &a->b Cc: gcc-patches@gcc.gnu.org X-SW-Source: 2004-10/txt/msg01536.txt.bz2 I think that should still be the general case; if we're taking the address of, say, a struct returned from a function, we want to propagate TREE_SIDE_EFFECTS from the call to the ADDR_EXPR. I wonder if the problem isn't here: if (TREE_CODE (node) == INDIRECT_REF) { /* If this is &((T*)0)->field, then this is a form of addition. */ if (TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST) UPDATE_TITCSE (node); Shouldn't that last "node" be TREE_OPERAND (node, 0)? We don't care about the INDIRECT_REF here: all we care about is its operand.