From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29943 invoked by alias); 25 Sep 2004 02:59:42 -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 29932 invoked from network); 25 Sep 2004 02:59:41 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 25 Sep 2004 02:59:41 -0000 Received: from [127.0.0.1] (HELO [127.0.0.1]) by dberlin.org (CommuniGate Pro SMTP 4.2.1) with ESMTP-TLS id 7338262; Fri, 24 Sep 2004 22:59:40 -0400 Subject: Re: Re: From: Daniel Berlin To: Dale Johannesen Cc: Devang Patel , gcc@gcc.gnu.org In-Reply-To: References: <044DA5B8-0E8E-11D9-80A2-000A95D7CD40@apple.com> <9D4EDFF8-0E91-11D9-AC54-000393A91CAA@apple.com> Content-Type: text/plain Date: Sat, 25 Sep 2004 11:14:00 -0000 Message-Id: <1096081180.16121.1.camel@dberlin.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg01463.txt.bz2 On Fri, 2004-09-24 at 19:36 -0700, Dale Johannesen wrote: > On Sep 24, 2004, at 6:24 PM, Devang Patel wrote: > > On Sep 24, 2004, at 5:58 PM, Dale Johannesen wrote: > >> I'm tracking down a crash I'm getting locally. It's not clear yet > >> this is connected, > >> but I see a tree of this form in the Gimple and SSA dumps: > >> > >> *pTmp4 = __NAGf90_dcdivdc (*pTmp2, *pTmp3); > >> > >> The Gimple doc does not allow a pointer deref in a function argument. > >> Is is supposed to? > > > > It says CALL_EXPR arguments are valid LHS. So it allows. I am reading > > comment at the beginning of tree-gimple.c > > Thanks, I was looking at tree-ssa.texi: > > call-stmt: CALL_EXPR > op0 -> _DECL | '&' _DECL > op1 -> arglist > arglist: > NULL_TREE > | TREE_LIST > op0 -> val > op1 -> arglist > val : _DECL | CONST > > There seem to be a number of differences. Apparently the > tree-ssa.texi version is older, as it's > closer (but not identical) to the summit paper, but some nits have > crept in. The version in > tree-gimple.c doesn't seem to allow ADDR_EXPR, but clearly it has to: > > __NAGf90_write (6, &FMT_129, -1, 0B, 0, 0); > Actually, it *doesn't* allow random ADDR_EXPR. We consider min_invariant things to be CONST. That's why you see & in the arglist, becuase it's invariant. Random ADDR_EXPR's are *NOT* allowed in the call argument list, nor should they be. --