From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5556 invoked by alias); 23 Aug 2012 18:01:40 -0000 Received: (qmail 5544 invoked by uid 22791); 23 Aug 2012 18:01:39 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_BD,TW_QE 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, 23 Aug 2012 18:01:25 +0000 From: "matt at use dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/53676] [4.7 regression] empty loop is not always removed now Date: Thu, 23 Aug 2012 18:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: matt at use dot net X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.2 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: 2012-08/txt/msg01640.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #16 from Matt Hargett 2012-08-23 18:01:08 UTC --- Back/forward-porting of the "trivial" restoration of the old behavior is acceptable to me, as it would remove a major barrier to our adoption of 4.7.x. That being said, if there's multi-platform testing I can do with a 'better' fix based on trunk, I have SPARC and ARM qemu environments set up to regression test on. BTW, I realized that my initial analysis was wrong -- the int32_t and uint32_t benchmarks are unaffected by this regression. Let me know if there's an easy way to apply the restoration patch and I'll test it locally on our amdfam10 and bdver2 hardware. If the testcase committed to trunk would be applicable to a 4.7 fix as well, I can make a patch to integrate that to ensure thie functionality doesn't regress again in future 4.7.x point releases. I'm happy to do as much footwork as my expertise allows, just let me know :) Thanks!