From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 526 invoked by alias); 13 Sep 2013 15:48:54 -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 467 invoked by uid 48); 13 Sep 2013 15:48:51 -0000 From: "su at cs dot ucdavis.edu" 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:48: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: su at cs dot ucdavis.edu 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/msg00997.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #15 from Zhendong Su --- (In reply to Jeffrey A. Law from comment #14) > 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. > Thanks Jeff; that's what I thought. I noticed a stackoverflow discussion on this very topic: http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior Perhaps you folks could help inject some clarity to that discussion. > 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. > I see. But would it be better to inform the programmers instead? Please see this recent interesting work to appear at the upcoming SOSP conference: http://css.csail.mit.edu/stack/ "Optimization-unstable code (unstable code for short) is an emerging class of software bugs: code that is unexpectedly eliminated by compiler optimizations due to undefined behavior in the program. Unstable code is present in many systems, including the Linux kernel and the Postgres database server. The consequences of unstable code range from incorrect functionality to missing security checks. STACK is a static checker that detects unstable code in C/C++ programs. Applying STACK to widely used systems has uncovered 150+ new bugs that have been confirmed and fixed by developers." > 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.