Re: PATCH RFC: Warn about pointer wraparound with -Wstrict-overflow

[Ian Lance Taylor <iant at google dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> Ian Lance Taylor wrote:
>> Mark Mitchell <mark@codesourcery.com> writes:
>>
>>> * I think Richard's right that this is a new feature for 4.2, which
>>> means we would have to bend the rules to put it in.  But, the patch
>>> seems very safe by its construction, since flag_strict_overflow is
>>> usually false.  So, I think it should be in 4.2.  Jakub, Joseph, what
>>> say you?
>>
>> Note that flag_strict_overflow defaults to true when using -O2.
>
> Excellent point.
>
> That does up the risk a bit, since it means we are more likely to take
> the new code paths.  You're making optimization more aggressive, if I
> understand correctly, in that we'll now optimize based on pointers not
> overflowing.  I agree with Richard that in this case we should avoid
> this for 4.2; it seems like we might break existing programs in the
> field and it would be better to do that in 4.3.1, than on the 4.2
> branch.

No, I am making the optimization less aggressive.

In gcc 4.2, the optimization currently fires if -fno-wrapv and
-fno-trapv.  When I backport my patch to gcc 4.2, the optimization
will additionally require -fstrict-overflow.  That is, in current gcc
4.2, the optimization fires even at -O0 (in general--of course the
folder is called more often when optimizing).  When my patch is
backported, it will only fire when -fstrict-overflow is used, which
means in typical cases it will only fire at -O2.

In gcc 4.3 and 4.4, the optimization currently fires unconditionally.
With my current patch, it only fires if -fno-wrapv, and -fno-trapv,
and -fstrict-overflow.

I believe my patch is quite safe in the sense that it will optimize
less often.  However, it will cause more warnings when using
-Wstrict-overflow=3 or higher (not the default), and of course some
people might see the lack of optimization at -O1 as a regression.

Ian