[Bug tree-optimization/70623] [4.9/5/6 Regression] ICE in compute_antic at -O2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70623

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
"Patch" in testing.  Note that the issue seems to be oscillating values because
of bitmap_set_and only taking expressions from 'dest', pruning out those
for which the value-and removed their value.  But

mem_ref<0B>,addr_expr<&av>}@.MEM_5 (0005)
mem_ref<0B>,av.0_8}@.MEM_7(D) (0006)
_9 (0006)

and with only 0006 in the value-and but mem_ref<0B>,av.0_8}@.MEM_7(D) (0006)
in the expr-set we get 0006 dropped in clean ().  In a different iteration
mem_ref<0B>,av.0_8}@.MEM_7(D) gets exchanged for _9 (0006) and it re-appears.

The solution seems to be to union the expr-sets in bitmap_set_and before
pruning expressions no longer in the value-intersection.

But then clean () uses bitmap_remove_from_set which does

  unsigned int val  = get_expr_value_id (expr);
  if (!value_id_constant_p (val))
    { 
      bitmap_clear_bit (&set->values, val);
      bitmap_clear_bit (&set->expressions, get_expression_id (expr));
    }

and thus seems to rely on there being exactly one expression for each value
in a bitmap-set.  bitmap_find_leader does

  if (bitmap_set_contains_value (set, val))
    {
      unsigned int i;
      bitmap_iterator bi;
      bitmap exprset = value_expressions[val];

      EXECUTE_IF_AND_IN_BITMAP (exprset, &set->expressions, 0, i, bi)
        return expression_for_id (i);

so kind-of would agree with that.