From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-295077-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30742 invoked by alias); 23 Jun 2011 14:14:40 -0000
Received: (qmail 30733 invoked by uid 22791); 23 Jun 2011 14:14:39 -0000
X-SWARE-Spam-Status: No, hits=-3.5 required=5.0	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 14:14:25 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2])	by mx2.suse.de (Postfix) with ESMTP id 442F4867E2;	Thu, 23 Jun 2011 16:14:24 +0200 (CEST)
Date: Thu, 23 Jun 2011 14:37:00 -0000
From: Martin Jambor <mjambor@suse.cz>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Xinliang David Li <davidxl@google.com>,	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: SRA generates uninitialized var use
Message-ID: <20110623141423.GA2736@virgil.arch.suse.de>
Mail-Followup-To: Richard Guenther <richard.guenther@gmail.com>,	Xinliang David Li <davidxl@google.com>,	GCC Patches <gcc-patches@gcc.gnu.org>
References: <BANLkTikriRpAsKzCX_=cAvOZX3M0SGdgRg@mail.gmail.com> <BANLkTimCa+iAU5JOXCk1b2Z9CK+54SmUaA@mail.gmail.com> <BANLkTinrAFzWvYL2ZT9ADV8vekAx9z8urrieJgWdQGVAfyZrcA@mail.gmail.com> <BANLkTimQ1hjB=TnmZ3RMVOCWxOxM6ARK2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTimQ1hjB=TnmZ3RMVOCWxOxM6ARK2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-06/txt/msg01762.txt.bz2

Hi,

On Mon, Jun 20, 2011 at 10:47:58PM +0200, Richard Guenther wrote:
> On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li <davidxl@google.com> wrote:
> > It is used to indicate the fact the var decl needs to have a memory
> > home (addressable) -- is there another way to do this? this is to
> > avoid the following situation:
> >
> > 1) after SRA before update SSA, the IR looks like:
> >
> >   MEM[.... &SR_123] = ...
> >
> >   other_var = SR_123;   <---- (x)
> >
> >
> > In this case, SR_123 is not of aggregate type, and it is not
> > addressable, update_ssa won't assign a VUSE for (x), leading to
> 
> The point is, SRA should never have created the above
> 
>   MEM[.... &SR_123] = ...
> 
> Martin, why would it even create new _memory_ backed decls?

This is now PR 49516.  I will submit a patch later today after
bootstrapping and testing it.

Martin


> 
> Richard.
> 
> > 2) final IR after SRA:
> >
> >   MEM[..., &SR_123] = ..
> >   other_var = SR_123_yyy(D);
> >
> >
> > David
> >
> > On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther
> > <richard.guenther@gmail.com> wrote:
> >> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li <davidxl@google.com> wrote:
> >>> Compiling the test case in the patch with -O2 -m32 without the fix,
> >>> the program will abort. The problem is a var decl whose address is
> >>> taken is not marked as addressable leading to bad SSA update (missing
> >>> VUSE).  (the triaging used the the .after and .after_cleanup dump diff
> >>> and found the problem).
> >>>
> >>> the test is on going. Ok after testing?
> >>
> >> That doesn't make sense.  SRA shouldn't generate anything that has
> >> its address taken.  So, where do we take its address?
> >>
> >> Richard.
> >>
> >>> Thanks,
> >>>
> >>> David
> >>>
> >>
> >