Mark Mitchell - Re: PATCH RFC: -Wstrict-overflow (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]