https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102648
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> --- This is another case of insufficient range representation in the old value_range. The patch causing the issue allows us to produce better subranges when the source ranges have small numbers of constants in them. We have the sequence: g.8_18 = (unsigned short) _2; _19 = g.8_18 * 40000; _20 = (short int) _19; if (_20 > 1) we calculate that g.8_18 has a range of [0,1] before this patch, we calculated: _19 = unsigned short ~[1, 39999] _20 = short int [-25536, 0] if (_20 > 1) could then be folded as never taken. With the precision change, we calculate _19 as [0,0][40000,40000], which when converted to a value range, becomes [0,40000]. This then causes _20 be calculated as short int ~[-25535, -1] which can no longer correctly predict that the branch can never be taken. This problem goes away if we run another evrp instance later instead of VRP as this is a non issue with multi-ranges as we get: g.8_18 : unsigned short [0, 1] _19 : unsigned short [0, 0][40000, 40000] _20 : short int [-25536, -25536][0, 0] and can easily fold away the condition.
