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.