Re: [PATCH] Fix PR52756

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Apr 2, 2012 at 5:32 AM, Richard Guenther <rguenther@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 ?<rguenther@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?

-- 
H.J.