This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH COMMITTED: gcc 4.2 support for -Wstrict-overflow/-fstrict-overflow
On 3/12/07, Mark Mitchell <mark@codesourcery.com> wrote:
Richard Guenther wrote:
> On 3/12/07, Andrew Pinski <pinskia@gmail.com> wrote:
>> On 11 Mar 2007 21:40:24 -0700, Ian Lance Taylor <iant@google.com> 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
VARYING). Consider:
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.
Richard.