From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11238 invoked by alias); 7 Jul 2011 19:32:17 -0000 Received: (qmail 11227 invoked by uid 22791); 7 Jul 2011 19:32:16 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_DX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jul 2011 19:31:58 +0000 From: "xinliangli at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: regression X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: xinliangli at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 07 Jul 2011 19:32:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00536.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #9 from davidxl 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 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 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. >