SRA generates uninitialized var use

Martin Jambor mjambor@suse.cz
Thu Jun 23 14:37:00 GMT 2011


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
> >>>
> >>
> >



More information about the Gcc-patches mailing list