https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120661
--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #3) > This is in main, I only see one create_basic_block there during expansion > (the one added on edge from ENTRY to ENTRY->succ) and no remove_edge, no > further edges redirected or added. > Andrew, could you please have a look? > I see e.g. > recomputation attempt on edge 4->5 for _34 = _5 + 1; > message appearing 7000+ times after Ctrl-C very early, so ranger is looping > there. I see a cache cycle for computation of _7 between bb4 and bb5. those 2 blocks feed each other, and when a new value is computed, there are slight differences in the bitmask associated with the range. It starts at [irange] int [-INF, -8][0, 0][8, +INF] MASK 0xfffffff8 VALUE 0x0 and when that value is fed back into the computation, it eliminates a possible range in one of the calculations, and the next iteration ends up calculating: [irange] int [-INF, -8][0, 0][8, +INF] MASK 0xfffffffd VALUE 0x0 and the third time through, we end up calculating the range with no mask [irange] int [-INF, -8][0, 0][8, +INF] and that value then causes the first one to be generated again. the range does not compare equal because of the changing bitmasks. We've run into this sort of thing before which happens because we do not have a canonical representation of bitmasks for a range. I had started work on that but it is not trivial. The cache update, because it is the only cyclical thing we have, should probably be changed to either not compare the bitmasks for updates, or check if the new bitmask is less restrictive than the old... Im not sure the best solution immediately... Let me experiment
