https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #2)
> I thought we don't, if the testcase starts with
> void dummy (void);
> short int foo (void);
> int src(void) {
> short int num = foo ();
> switch(num){
> instead then evrp1 optimizes away the BIT_AND_EXPR.
> Though, if the ranger just has a known zero mask in addition to normal
> ranges, maybe it can't handle it, because the range of num with (short)num
> == 111 is hard to express
> (it would be a union of 65536 ranges).
> Maybe bit-ccp should be able to handle that though, this case is exactly that
> upper 16 bits of the value are uknown and lower 16 bits of the value are all
> known,
> some of them 0, some of them 1.
> But maybe bit-ccp doesn't handle switches.
We certainly do fully handle switches.
The problem is the case is on a cast and then we use num in its fullsize in
the expression. So its all the other bits:
num_5(D) [irange] int [-INF, -65537][-65425, -65425][111, 111][65536,
+INF]
<bb 3> :
<L0>:
_8 = num_5(D) & 65534;
goto <bb 5>; [INV]
_8 : [irange] int [0, 65534] MASK 0xfffe VALUE 0x0
Given it starts with:
_1 = (short int) num_5(D);
_2 = (int) _1;
switch (_1) <default: <L4> [INV], case 111: <L0> [INV], case 204: <L6>
[INV], case 263: <L6> [INV], case 267: <L6> [INV]>
Its difficult to recognize that the known bits of 'num_5' match each switch
case.
