From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12168 invoked by alias); 21 Jun 2011 08:42:54 -0000 Received: (qmail 12157 invoked by uid 22791); 21 Jun 2011 08:42:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jun 2011 08:42:35 +0000 Received: by wwi18 with SMTP id 18so17681wwi.2 for ; Tue, 21 Jun 2011 01:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.174.69 with SMTP id s5mr856502wbz.80.1308645754091; Tue, 21 Jun 2011 01:42:34 -0700 (PDT) Received: by 10.227.36.212 with HTTP; Tue, 21 Jun 2011 01:42:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jun 2011 08:56:00 -0000 Message-ID: Subject: Re: SRA generates uninitialized var use From: Richard Guenther To: Xinliang David Li Cc: GCC Patches , Martin Jambor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01569.txt.bz2 On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li wro= te: > Good point -- but why does SRA have to be so complicated? If it just > do structure expansion and let subsequent phases to clean it up, would > it be simpler? Anyway this is off the topic. Well, it's certainly non-optimal to insert new memory backed variables to get rid of memory backed variables ... Richard. > Thanks, > > David > > > On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther > wrote: >> On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li = 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: >>> >>> =A0 MEM[.... &SR_123] =3D ... >>> >>> =A0 other_var =3D SR_123; =A0 <---- (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 >> >> =A0MEM[.... &SR_123] =3D ... >> >> Martin, why would it even create new _memory_ backed decls? >> >> Richard. >> >>> 2) final IR after SRA: >>> >>> =A0 MEM[..., &SR_123] =3D .. >>> =A0 other_var =3D SR_123_yyy(D); >>> >>> >>> David >>> >>> On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther >>> wrote: >>>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li 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). =A0(the triaging used the the .after and .after_cleanup dump d= iff >>>>> and found the problem). >>>>> >>>>> the test is on going. Ok after testing? >>>> >>>> That doesn't make sense. =A0SRA shouldn't generate anything that has >>>> its address taken. =A0So, where do we take its address? >>>> >>>> Richard. >>>> >>>>> Thanks, >>>>> >>>>> David >>>>> >>>> >>> >> >