[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

["xinliangli at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498

--- Comment #9 from davidxl <xinliangli at gmail dot com> 2011-07-07 19:31:53 UTC ---
On Thu, Jul 7, 2011 at 9:23 AM, law at redhat dot com <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
>
> --- Comment #8 from Jeffrey A. Law <law at redhat dot com> 2011-07-07
> 16:22:48 UTC ---
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/05/11 16:52, xinliangli at gmail dot com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
> >
> > --- Comment #7 from davidxl <xinliangli at gmail dot com> 2011-07-05
> 22:51:49 UTC ---
> > (In reply to comment #6)
> >> Created attachment 24693 [details]
> >> k.c.127t.uninit
> >
> >
> > 1) is the complicated control flow generated by if-merging +
> jump-threading?
> I think jump-threading is the primarly culprit.  At one time I tried to
> track how things changed through the passes, but ultimately decided the
> end result either had to be analyzable or not by the uninit code.
>
> > 2) On the targets that have the problem, is branch cost considered cheap?
> No idea.  I didn't bother to look at why cris-elf triggers the problem,
> but x86 doesn't.  Presumably it's a branch-cost or similar issue.
>
> > 3) Looks like there are more jump-threading opportunities that can clean
> up the
> > control flow, namely,
> Yes.  Jump threading is inherently an iterative process.  It was decided
> some time ago to remove the iterative step as it doesn't buy a whole lot
> in terms of code quality and it's a fairly significant compile-time cost.
>

Does it need to be iterative? Any simple example to show dependency of
jump-threading analysis on actual transformation of some other
jump-threading instance (e.g, opportunity only gets exposed after
transformation)?


>
> During my investigations noticed the same thing and manually reran DOM
> from within GDB and verified it further simplified the CFG, but
> rerunning DOM isn't really going to be an option.
>

Is incremental DOM update a choice?

David


>
>
> >
> > With the complicated control flow, the uninit analysis is definitely
> confused
> > -- requires powerful symbolic evaluation to simplify the predicates: the
> > predicates guarding the use in BLOCK 6:
> >
> > (n<=9 AND  m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9
> AND m
> >> 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100))
> >
> > of course there might be other bugs in the analysis that prevent the
> above from
> > formulated, but nonetheless, it is unlikely to be handled).
> OK.  That's kindof what I needed to know -- we're unlikely to handle
> this particular case.
>
> >
> > Solution
> > 1) fix the test case by disabling jumpthreading and if-merging
> Or xfailing it for the affected targets.
>
> > 2) or maybe move the uninit analysis earlier in the pipeline.
> As you know, that runs the risk of introducing other false positives.
>
> I can live with #1 or the target-specific xfailing approach.
>
> jeff
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOFd1BAAoJEBRtltQi2kC7wpsIAJ1FStgYozE/6o8o5mZrj+5V
> hWP7WmspSVFQMLTGDZw7hNeCEnE2rIl/8Tmin6/GDWM50oNGati2HqTRqTSZwU0y
> YvMY8NlH1/YY4hJ94YPEpNrALAIwD8w3qdhiPVlS7eTWgOl8iTmXLJmJqk6OnT+Z
> BeYPxpYDkQgYvicyjT4VVcWpwcmCbE/D9bKTNt68ABAH8RTmkba/VaK1wtGpt3qt
> hy0qXCi59OUPh7TbcKvgrDLL3GDmy68C9afHUiEKyfDu3JxV9awl4y4Bfr1lOURF
> bvTOuhKQo0MOlbtgJo24nGYK2TU/1Nv1DkcdhgvsCCBciO8LPoocnSZ176ohE5E=
> =/ti9
> -----END PGP SIGNATURE-----
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>