From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14119 invoked by alias); 4 May 2012 16:16:00 -0000 Received: (qmail 14098 invoked by uid 22791); 4 May 2012 16:15:56 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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; Fri, 04 May 2012 16:15:43 +0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2 Date: Fri, 04 May 2012 16:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2012-05/txt/msg00451.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53128 --- Comment #7 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 2012-05-04 16:15:09 UTC --- (In reply to comment #6) > Compiler does not simply see such code, it happens after some analysis, r= ight? > For example, after work of infer_loop_bounds_from_undefined which makes s= ome > assumptions and I believe can produce some information for user. My understanding is that this is non-trivial to do from within the current passes because "undefined" in that context does not mean "this code is wron= g" but "we don't know what happens here but we can assume what doesn't happen"= . So perhaps a new pass looking specifically for infinite loops could be more effective. In any case, if you know how to do it, please propose a patch, so people can discuss it. If there is way to warn for this that doesn't generate an awful number of false positives, I think such patch would be very welcome. > Again, I'm worrying about all this from user-perspective and especially a= fter > discovering 2 such things in spec2006 sources(PR53086 and PR53073). I think there is no discussion about whether GCC would like to have such a warning. What is not clear is the best way to do it. So please, test your i= deas and send a prototype of your patch for discussion. People are more likely to give you feedback when there is something concrete to discuss about.