JDK-8277850 added some new Value() optimizations in AndI/AndL to optimize pattern similar to "(v << 2) & 3" which can directly be replaced by zero. To do that, we look at the type of the shift value of the LShift input.

This optimization works fine but causes problems in CCP. After calling Value() for a node in CCP, we only add the direct users of it back to the worklist if the type changed. We special case some nodes where we need to add additional nodes back to the worklist to not miss updating them. We should also explicitly add AndI/AndL users of an LShift node that is being put on the worklist. In rare cases, we could wrongly replace and AndI/AndL node by zero in CCP because we miss another Value() call. This can lead to a wrong execution which was found by the attached reduced fuzzer test:

$ java -Xint Test.java > int
$ java -Xbatch Test.java > c2
$ diff int c2
1c1
< result: 35072
---
> result: 0

We could think about adding a new verification phase to CCP to call Value() for each node one more time after we've reached a fixed point. Finding another type change could indicate a bug. This, however, should be investigated separately.