From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11858 invoked by alias); 12 Mar 2013 14:15:00 -0000 Received: (qmail 11542 invoked by uid 48); 12 Mar 2013 14:14:01 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count Date: Tue, 12 Mar 2013 14:15: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: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW 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" 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: 2013-03/txt/msg00954.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265 --- Comment #20 from Jakub Jelinek 2013-03-12 14:13:56 UTC --- Ok, based on reading what exactly record_estimate does, I've tried: --- tree-ssa-loop-niter.c.xx 2013-03-12 13:47:08.000000000 +0100 +++ tree-ssa-loop-niter.c 2013-03-12 15:01:50.498107788 +0100 @@ -2655,7 +2655,10 @@ record_nonwrapping_iv (struct loop *loop && warn_aggressive_loop_optimizations && (cfun->curr_properties & PROP_loops) != 0 && !loop->warned_aggressive_loop_optimizations - && max.ucmp (tree_to_double_int (loop->nb_iterations)) < 0) + && (upper || realistic) + && (max + double_int_one).ucmp (tree_to_double_int (loop->nb_iterations)) + < 0 + && dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (stmt))) { location_t loop_locus = UNKNOWN_LOCATION; edge e = single_exit (loop); incremental patch (for !upper && !realistic it gives up early, for !dominated_by_p it records the bounds, but doesn't call record_niter_bound, and record_nonwrapping_iv calls unconditionally record_estimate with is_exit=false, for which it adds double_int_one to the bounds. With this #c16 and #c17 compile without warnings, unfortunately the testcase in the patch regresses two tests, fn4 and fn7 (the latter is from the SPEC2k6 issue). max + double_int_one above is unsafe btw, we'd need something that record_estimate does to check for overflows.