Re: Question about -Wstrict-overflow=2

[Martin Sebor <msebor@gmail.com>]

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