On Mon, 2 Apr 2012, H.J. Lu wrote:

> On Mon, Apr 2, 2012 at 5:32 AM, Richard Guenther <rguent...@suse.de> wrote:
> >
> > After going through a gazillion of candidate fixes for PR52756, a
> > case where jump threading destroys loops in a non-recoverable way,
> > I settled with the following.  The issue is that we thread both
> > the loop latch and the loop entry edge but the code is not prepared
> > for that.  Another possible fix would be to unconditionally throw
> > away threadings if we threaded the latch based on the fact that
> > the rest of the edges no longer are loop entry edges (but threading
> > them may create one, I think even still one that will end up
> > creating a multiple entry loop).
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > Thanks,
> > Richard.
> >
> > 2012-04-02  Richard Guenther  <rguent...@suse.de>
> >
> >        PR tree-optimization/52756
> >        * tree-ssa-threadupdate.c (thread_through_loop_header): After
> >        threading through the loop latch re-start the function to
> >        double-check the rest of the threading opportunities.
> >
> >        * gcc.dg/torture/pr52756.c: New testcase.
> >
> > Index: gcc/testsuite/gcc.dg/torture/pr52756.c
> > ===================================================================
> > *** gcc/testsuite/gcc.dg/torture/pr52756.c      (revision 0)
> > --- gcc/testsuite/gcc.dg/torture/pr52756.c      (revision 0)
> > ***************
> > *** 0 ****
> > --- 1,9 ----
> > + /* { dg-do compile } */
> > +
> > + void Env_FetchObj0AttrOffset (unsigned int NumFields,  int *Status)
> > + {
> > +   int Found = 0;
> > +   if (NumFields)
> > +     while ((*Status == 0) && NumFields-- > 0 && Found == 0)
> > +       Found = 1;
> > + }
> 
> Is compiler allowed to optimize this function into an empty body?
> Will it be a useful testcase then?

I don't think so as *Status may trap.

Richard.

Reply via email to