https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- I think y'all have it all figured out. Basically, operator_cast::op1_range() is solving num_5 in the equation: [111,111] = (short int) num_5 Where lhs is: (gdb) p debug(lhs) [irange] short int [111, 111] And the bitmask is implicit, but correctly calculated: (gdb) p debug(lhs.get_bitmask ()) MASK 0x0 VALUE 0x6f And the range for num_5 is just varying. You are looking at the true side of the truncating_cast_p() conditional in op1_range. Essentially, once it starts building the range it ignores known bitmasks, which cause it to return an overly conservative range. And yes, bitmasks are calculated on demand per the comment in get_bitmask: // The mask inherent in the range is calculated on-demand. For // example, [0,255] does not have known bits set by default. This // saves us considerable time, because setting it at creation incurs // a large penalty for irange::set. At the time of writing there // was a 5% slowdown in VRP if we kept the mask precisely up to date // at all times. Instead, we default to -1 and set it when // explicitly requested. However, this function will always return // the correct mask. We may have to revisit this. Perhaps it doesn't matter any more, and we could keep bitmasks up to date. It would definitely make the dumps easier to read. Though, at least for this testcase the bitmask is correctly returned with get_bitmask(). I think the analysis in comment 11 is spot on. And no Andrew, it's not *my* code, it all comes from the bit-ccp code :-P. fold_range() should call update_bitmask(), which eventually calls bit_value_binop() in the CCP code. And yes Jakub, as you have noticed, BIT_IOR_EXPR, BIT_XOR_EXPR, and likely other operators may need to be tweaked to take bitmasks into account. I wouldn't be surprised if there's a lot of low hanging fruit in this space.
