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

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.

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.


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