From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10923 invoked by alias); 7 Sep 2004 12:38:35 -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 10914 invoked from network); 7 Sep 2004 12:38:34 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 7 Sep 2004 12:38:34 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA24626; Tue, 7 Sep 04 08:41:34 EDT Date: Tue, 07 Sep 2004 12:38:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10409071241.AA24626@vlsi1.ultra.nyu.edu> To: amacleod@redhat.com Subject: Re: Problem with operand handling Cc: gcc@gcc.gnu.org X-SW-Source: 2004-09/txt/msg00284.txt.bz2 The only time &var is used as a pointer is if the variable passes the test 'is_gimple_reg()'. Only real operands store this pointer value. If var is a virtual SSA_NAME operand, then we store *var into a tree and keep that value around. I think this is pre-ssa-conversion, so it's still a VAR_DECL. I didn't see any code to do that copying. So this should only be causing you a problem if you have an is_gimple_reg() which is being passed to add_stmt_operand in this manner. The thats a bug. It was happening via a TMT "variable".