[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)

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387

--- Comment #15 from Zhendong Su <su at cs dot ucdavis.edu> ---
(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.