http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #16 from Jeffrey A. Law <law at redhat dot com> --- The optimization came out of building additional warnings for GCC. It's safe to assume that there'll be an option to enable a warning that the compiler was able to identify and isolate a path with undefined behaviour. Sadly these paths are not uncommon and it is often exceedingly difficult to prove if the path is truly unexecutable or not. The net result is there's going to be a fair amount of noise from this warning when tested on real world code. To give you a sense of scale, there's thousands of these paths in GCC itself. I analyzed many of them. To date I haven't found a single one that was actually executable at run time -- but to prove the paths are unexecutable we have to have analysis that can span multiple compilation units and a much more powerful mechanism to replace the jump threading code. However, each of these instances certainly represents an opportunity to do some real in depth analysis and potentially improve GCC's analysis/optimization and/or restructure the source in such ways as to avoid the problematic paths. In both instances the resulting compiler is marginally faster. And, yes, if you look at something like Coverity, these are precisely the kinds of things it's warning about as well.
