PATCH COMMITTED: gcc 4.2 support for -Wstrict-overflow/-fstrict-overflow
Tue Mar 13 12:29:00 GMT 2007
On 3/12/07, Mark Mitchell <firstname.lastname@example.org> wrote:
> Richard Guenther wrote:
> > On 3/12/07, Andrew Pinski <email@example.com> wrote:
> >> On 11 Mar 2007 21:40:24 -0700, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> >> > I have just committed the gcc 4.2 patch which adds support for
> >> > -Wstrict-overflow and -fstrict-overflow, as previously approved. A
> >> > bunch of testing was required. Lucky for me that Mark's release
> >> > candidate was delayed.
> >> Wait, this still introduces a missed optimization regression as
> >> mentioned by Richard Guenther so why did you apply it before that was
> >> resolved?
> > As far as I understand the patch will always introduce missed-optimization
> > regressions for "artificial" testcases - it's just the way the patch
> > is designed.
> Would you please point me at an example of the kind of regression we
> will see?
> Based on what you've said, and my understanding of the patch, I think
> that we're making the right usability tradeoff. However, I'd be
> intersted in looking at the kinds of test cases that will regress, and I
> appreciate you bringing the issue to my attention.
As far as I understand we will get regressions whenever intermediate propagation
causes an overflow. Basically an overflowed infinity is "sticky" in
the value ranges,
we preserve it for all costs (or avoid using it by dropping to
if (a < 0)
a = -a; // now a has the range [1, +INF(OVF)]
a = a - 1; // we now either get [0, +INF(OVF)] or drop to
VARYING, we don't
// get [0, INT_MAX - 1] as we got before the patch.
if (a != INT_MAX) // we cannot fold this anymore
Maybe Ian can clarify if I got things wrong.
The only way we can avoid these kind of issues is to track two value ranges, one
where we assume wrapping semantics and one where we assume undefined overflow
behavior. Which comes at another cost, of course.
More information about the Gcc-patches