From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10706 invoked by alias); 27 Feb 2004 00:21:55 -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 10697 invoked from network); 27 Feb 2004 00:21:54 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 27 Feb 2004 00:21:54 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i1R0Lpb10338; Thu, 26 Feb 2004 19:21:51 -0500 Received: from speedy.slc.redhat.com (vpn50-43.rdu.redhat.com [172.16.50.43]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i1R0Ln814181; Thu, 26 Feb 2004 19:21:50 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id i1R0Liju019534; Thu, 26 Feb 2004 17:21:44 -0700 Message-Id: <200402270021.i1R0Liju019534@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Dale Johannesen cc: GCC List Reply-To: law@redhat.com Subject: Re: IMA vs tree-ssa In-Reply-To: Your message of "Thu, 26 Feb 2004 16:09:59 PST." <47CEA8A4-68B9-11D8-8C0E-000A95D7CD40@apple.com> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Feb 2004 01:05:00 -0000 X-SW-Source: 2004-02/txt/msg01420.txt.bz2 In message <47CEA8A4-68B9-11D8-8C0E-000A95D7CD40@apple.com>, Dale Johannesen wr ites: > >On Feb 26, 2004, at 3:47 PM, law@redhat.com wrote: >>> Because it's an array, so you get array = scalar. >> Ahhh. Then we ought to have a type test before returning base in that >> code. >> >>>> If OFFSET is nonzero, then we'll fall out returning NULL_TREE which >>>> indicates that we couldn't simplify -- which ought to just inhibit >>>> an optimization. >>> >>> Actually, I applied the fix rth suggested and now get an abort earlier >>> building 176.gcc. >>> Stay tuned. >> OK. Eagerly awaiting the next issue. > >The code in get_expr_operands() expects that *&x will get simplified, >and aborts if it isn't. I had a concern this might happen. > Both suggested fixes run into this. > >Perhaps maybe_fold_offset_to_array_ref ought to ignore the type >"mismatch", >at least when offset is 0. I can't see that *&x (for x an array) >should ever be anything but x[0]. Let me try that... My only concern would be that you might get a bad operand type mis-match; though for this code I don't really see how that could happen. jeff