https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877
--- Comment #2 from Stephan Beyer <s-beyer at gmx dot net> --- Hi, (In reply to Marc Glisse from comment #1) > The message seems pretty clear to me. gcc has an optimization that turns > i-1>i into false, and is telling you that it applied it (not that there is > anything wrong with your code). But it only applies it when doing some loop unrolling, doesn't it? Otherwise it would result in wrong behavior and the output wouldn't be the same. If this is the case, then the warning shouldn't be printed. > In the other code, it doesn't apply that > optimization, so the warning doesn't appear. Yes (that's why I wrote i >= 0 to see if it appears again). > Maybe we should just drop the warning if it causes more confusion than it > helps find bugs... The warning is a real problem in the case that can often be seen: when you turn on -O3 -Wall -Werror ... many people think that -Wall is so sensibly chosen by the compiler vendors that they can safely turn them into errors. However, in this case, -Wstrict-overflow is, according to you, more an information than an indication "that there is anything wrong with your code". Hence -Werror leading to an error somehow seems to be wrong behavior. On the other hand, warnings are mostly only an information about things going on implicitly, but you can usually make them explicit easily (e.g., variable assignments inside ifs by adding parentheses, implicit fallthroughs in switch/case by adding the [[fallthrough]] attribute, maybe-uninitialized warnings by initializing variables on declaration, etc.). In my example, however, the solution is to change the code into code using a break (which is considered bad style by some people) or by adding an extra bool variable (to avoid the break). And in another example, the solution may be totally different. It seems there is no "general" rule to get rid of these warnings before you experience them. Cheers Stephan
