Re: PATCH RFC: -Wstrict-overflow

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:

>> I think these warnings should be fixed before the patch goes in.  In
>> other words, I think we should make sure that no new warnings are
>> introduced during the GCC build process by the patch: either by
>> modifying GCC to not trigger the warnings or by modifying the patch to
>> not warn about stuff.
> 
> I've considered that.  It's a tradeoff: we can eliminate the warning
> in all cases, but it tends to make the resulting code a little
> uglier.  As you say later, it's a matter of: we know the values which
> will appear here are such that the calculations will never overflow.

> Here are some other examples:

...

> #define EDGE_FREQUENCY(e)		(((e)->src->frequency \
> 					  * (e)->probability \
> 					  + REG_BR_PROB_BASE / 2) \
> 					 / REG_BR_PROB_BASE)

Yeah, that's brutal.

The problem is that the warning (like some of the other warnings that we
use the middle-end infrastructure to produce) gets far away from the
user's code.  I'd bet many programmers would have a very hard time
tracking back from the warning message to the alleged problem.

To be honest, your examples are making me a little concerned that
-Wsigned-overflow isn't going to be much of a win.  It seems like many
programs are going to fall afoul of it, and that it will be hard to
silence.  So, except for the truly dedicated, willing to go through and
clean up (or selectively disable warnings) on each occurrence, this is
going to have a low signal-to-noise ratio.

I understand what we're trying to do: give users a heads-up about
possible situation where overflow might give surprising behavior,
because we will assume it can't happen.  But, if we can't the ratio up
to the point where the warning is telling you about something that's
probably a bug most of the time, it's not clear it's actually going to
be useful.

Is there any way to distinguish the:

  A * x / B

kinds of cases (which we can presume to be ordinary integer arithmetic
that just happens to be done on a computer with finite precision) from
these kinds of things:

  x + 1 > x
  abs(x) + 1 < 0

that (since they are always false for mathematical integers) are more
likely to be wrap-around tests?  In other words, can we make the warning
more selective by focusing on comparison operations?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713