Maybe. The bitwise_and op1_range is very complicated.. I think its
heavily used, so I would be surprised if it didn't. bitwise or was
doing nothing at all and showed up immediately when I tried a few
things. I think i just happned to hit it "lucky". It didnt fail any
existing cases, just the ones I was trying to make more complicated.
Do we want to port this to GCC14? Its pretty straightforward I think..
mostly cosmetic changes due to Value_Range and difference in the
range-query access to gori. Ive got it converted already, but noticed
there are some failures on the gcc14 branch? ie, seems to be:
FAIL: g++.dg/cpp23/attr-assume1.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume1.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume1.C -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume3.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume3.C -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume5.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume5.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume5.C -std=gnu++20 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume6.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume6.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/cpp23/attr-assume6.C -std=gnu++20 (test for excess errors
Andrew
On 11/1/24 15:45, Jakub Jelinek wrote:
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
