On 3/7/21 7:04 AM, Alexander Motzkau via Gcc-help wrote:
Andrew Haley wrote:
-Wstrict-overflow=2 triggers when GCC encounters expressions that
reduce to a constant, where that evaluation depends on overflow not
occuring. In this case the expression is
expbuf + 120 > get_buf()
If this is the case I can see the merit of the warning, because that can be
reduced to 120 > 0, which is a constant. But my problem ist, that I don't
see where this expression comes from? The condition in question is
argptr >= endbuf
which can be written as
expbuf + i >= expbuf + 120
which can be reduced to
i >= 120
which is not a constant, and therefore not a cause for this warning.
This could get constant if gcc does some loop unrolling, for the first loop
this would result in the expression you quoted. But then I would have hoped
that gcc doesn't warn about constants or dead code when unrolling a loop,
because they naturally happen then. And I can't do anything against it
except unrolling manually and this would make it less readable.
I doubt that it ever was. -Wstrict-overflow=2 is informative, for the
programmer. It doesn't suggest that anything is questionable about the
program, and in this case it's difficult or impossible to avoid.
If an originally non-constant if-expression is reduced to a constant one
that is for me something to worry about, where a warning/error is
appropriate. It means that the following block is always or never executed,
something the programmer usually didn't intend, otherwise he wouldn't have
written the if-condition.
And this reduction to a constant is what differentiates -Wstrict-overflow=2
from -Wstrict-overflow=3 (according to gcc's documentation). For the later
I would accept your description as it being purely informative.
Re upgrading: over time, GCC gets better and better at diagnosing and
providing information. This inevitably means that programmers using
-Werror with high levels of warnings have to change their programs
when a new GCC is used.
I understand and I welcome better analysis and optimization techniques.
And I changed several parts due to new warnings. But in this case I don't
see any possibility that wouldn't make the code worse except deactivating
the warning. Which is sad and normally beside the point of a warning.
In the case of flow-dependent warnings there often is a way to rewrite
the code in a way that make it either faster (because it helps GCC see
invariants it can't infer otherwise) or more readable.
I think rewriting the test as an equality would be an improvement:
argptr is incremented by 1 in each iteration so there's no way for
the pointer to be greater than endbuf.
if (argptr == endbuf)
return false;
This avoids the warning and has no change on the emitted code.
(Of course, if the step can be greater than 1 then using equality
wouldn't be appropriate.)
Martin
