From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13298 invoked by alias); 13 Sep 2013 15:28:53 -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 Received: (qmail 13216 invoked by uid 48); 13 Sep 2013 15:28:49 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes) Date: Fri, 13 Sep 2013 15:28: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-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: law at redhat dot com X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg00995.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #14 from Jeffrey A. Law --- It's the action of executing the code with undefined behaviour which is the trigger. ie, if you don't execute the code, then it has no effect on the defined/undefined state of the program as a whole. It's interesting that you mention undefined behaviour -- the primary motivation behind the patch that's causing this problem is to better expose to the analysis and optimization phases of GCC that certain paths, if executed, result in undefined behaviour. In particular, propagating NULL pointers into PHI nodes in non-dominated successors exposes more opportunities to identify paths which, if executed, would dereference a NULL pointer. We want to then isolate those paths which exhibit undefined behaviour from the rest of the code. That allows the "real" code paths to be better optimized and the undefined behaviour paths to be pulled out of the main instruction stream. The same can be done for out-of-bounds array accesses or uninitialized variables.