https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I really don't know how GORI etc. works. But, if when the switch handling determines that _1 (the switch controlling expression) has [irange] [111, 111] MASK 0x0 VALUE 0x6f (does it actually? i.e. for a singleton range all the bits here are known and equal to the value), then when trying to derive a range for related num_9(D) which is int rather than _1's short and _1 = (short int) num_5(D); for the MASK/VALUE we should just use the same VALUE and or in 0xffff0000 into MASK because we then don't know anything about the upper bits. Though, looking at the evrp detailed dump there is 2->3 _1 : [irange] short int [111, 111] 2->3 _2 : [irange] int [111, 111] 2->3 num_5(D) : [irange] int [-INF, -65537][-65425, -65425][111, 111][65536, +INF] and so no MASK/VALUE for any of those ranges. Now, from comments it seems that irange_bitmask is only computed on demand to speed things up, unless it has been explicitly set. Now, say for _1 or _2 above, we don't have anything recorded but we can always compute it on demand from the value range. But when adding the num_5(D) range based on the related _1 range, the on-demand irange_bitmask is no longer as precise as it would be if we when deriving that [-INF, -65537][-65425, -65425][111, 111][65536, +INF] range from the [111, 111] range also derived from the in that case on-demand asked MASK 0x0 VALUE 0x6f to MASK 0xffff0000 VALUE 0x6f.
