This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]