This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[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)
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 13 Sep 2013 16:02:44 +0000
- 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)
- Auto-submitted: auto-generated
- References: <bug-58387-4 at http dot gcc dot gnu dot org/bugzilla/>
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.