From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32676 invoked by alias); 27 Oct 2004 17:17:32 -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 32635 invoked from network); 27 Oct 2004 17:17:29 -0000 Received: from unknown (HELO mprelay.uc.edu) (129.137.3.48) by sourceware.org with SMTP; 27 Oct 2004 17:17:29 -0000 Received: from [172.30.2.187] (zhivago.erc-wireless.uc.edu [172.30.2.187]) by mprelay.uc.edu (MOS 3.4.7-GR) with ESMTP id BWR34571; Wed, 27 Oct 2004 13:17:24 -0400 (EDT) In-Reply-To: <1098896479.5943.22.camel@localhost.localdomain> References: <35DA558C-2559-11D9-8879-000A95D692F4@physics.uc.edu> <1098896479.5943.22.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10344B2B-283C-11D9-B7C0-000A95D692F4@physics.uc.edu> Content-Transfer-Encoding: 7bit Cc: GCC Patches From: Andrew Pinski Subject: Re: [PATCH] Fix PR tree-opt/17529, ICE due to *&a not being folded to a[0] Date: Wed, 27 Oct 2004 17:30:00 -0000 To: law@redhat.com X-SW-Source: 2004-10/txt/msg02380.txt.bz2 On Oct 27, 2004, at 1:01 PM, Jeffrey A Law wrote: > On Sat, 2004-10-23 at 21:08 -0400, Andrew Pinski wrote: >> I think the subject says what causes the problem and the reason why >> we don't fold *&a into a[0] is because fold does not handle it >> but fold_stmt does. > We might consider moving this logic into the fold one day, but I > suspect that's more intrusive than we want to tackle right now. > > However, I don't think this will fix the other testcase in that > PR: > > bar (const int *const x) > { > int x1 = *x; > } > static const int y[1]={0}; > void > foo (void) > { > bar (y); > } The other test is already fixed by the fact we call fold_stmt on MODIFY_EXPR already. In fact the only two places in gimple where INDIRECT_REF (at this point) can show up is ASM_EXPR or a MODIFY_EXPR so all cases are already handled. I tested the following the case where you might expect that the INDIRECT_REF might show up not in either ASM_EXPR or a MODIFY_EXPR but does not as we use a temporary variable to store the address: struct t { int i; }; void f(const int*const); bar (const struct t *const x) { f(&x->i); } static const struct t y[1]; void foo (void) { bar (y); } Thanks, Andrew Pinski