On Fri, Nov 01, 2024 at 03:25:37PM -0400, Andrew MacLeod wrote:
> When experimenting with more complex flow for the assume pass, I found a
> case where we were not as precise as we should be, but it was because
> range-ops hadn't been taught that if the LHS of a bitwise OR was positive,
> that the 2 RHS operands must also be positive.
>
> The testcase is simple a tweaked version of an existing testcase which
> turned
>
> if (a_1 < 0 && b_2 < 0) goto bb3; else goto bb4;
>
> into
> _4 = a_1 | b_2
> if (_4 < 0) goto bb3; else goto bb4;
>
> on the branch to bb4, the condition is _4 >= 0 and we were not getting
> positive values for a_1 and b_2 on that edge resulting in ranges that
> included [-INF, -1] that shouldn't have been there.
>
> This patch fixes that by implementing this functionality in op1_range in
> operator_bitwise_or, and adds the testcase.
Does the code handle properly also the case of if lhs of signed bitwise and
is negative, then both rhs1 and rhs2 are negative?
Jakub
