From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7380 invoked by alias); 9 Nov 2012 17:22:51 -0000 Received: (qmail 7370 invoked by uid 22791); 9 Nov 2012 17:22:49 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Nov 2012 17:22:44 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA9HMio8028753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Nov 2012 12:22:44 -0500 Received: from spoyarek (vpn-230-34.phx2.redhat.com [10.3.230.34]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA9HMf16032394; Fri, 9 Nov 2012 12:22:42 -0500 Date: Fri, 09 Nov 2012 17:22:00 -0000 From: Siddhesh Poyarekar To: Jan Hubicka Cc: Ian Lance Taylor , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll Message-ID: <20121109225145.10cf3541@spoyarek> In-Reply-To: <20121109163426.GA10002@atrey.karlin.mff.cuni.cz> References: <20121109184142.597e9d2c@spoyarek> <20121109163426.GA10002@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00768.txt.bz2 On Fri, 9 Nov 2012 17:34:26 +0100, Jan wrote: > > I don't mind saying that GCC should define cases that the language > > standards leave undefined. But that does not seem to be what this > > patch does. I don't see why this is a good idea. It seems to > > produce a program that is unpredictable in a different way. How > > does that help the user? If anything an infinite loop might be > > better, since it is more obvious that something is wrong. Unless I > > misunderstand. > > I think resonable thing to do is to output warning in this case > "Loop reaches undefined effect before any of the exit conditions are > satisfied; turned into infinite loop" or something along these > lines? We can probably even get the location info of the statement > that implied the loop bound. I had reckoned that the behaviour could be reverted to what was before while I figure out a way to get the warning in place for both cases, i.e. with tree-vrp (where max_loop_iterations now causes the loop to be folded away in -O2) and this unroll case (in -O1). I'll look at getting a warning for the tree-vrp case separately if the infinite loop behaviour needs to be retained. An infinite loop without the warning breaks diagnostic apps like valgrind since they are no longer in a position to detect this. The user would then have to somehow conclude that their loop loops infinitely because they have a beyond-array-bounds access in it. However, the infinite loop could be OK if there is an explicit warning telling the user that it's going to happen. I already have some rough code in place to do the warning against the loop header, so I'll clean it up to issue a warning for all exit points beyond the upper bound when we see that no exits remain. It will break a few existing test cases though - I had posted a patch to fix those earlier today: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00722.html Thanks, Siddhesh