https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81931
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Aldy Hernandez from comment #6) > The problem here is that get_nonzero_bits() is being called with an SSA > whose precision is 0 (_Complex float). This is causing this code in > get_nonzero_bits(): > > range_info_def *ri = SSA_NAME_RANGE_INFO (name); > if (!ri) > return wi::shwi (-1, precision); > > ...to return a wide int of: > > (gdb) p nonzero_bits.dump() > [0], precision = 0 > > whereas previous to the aforementioned patch, we were returning: > > (gdb) p nonzero_bits.dump() > [0xffffffffffffffff], precision = 0 > > This discrepancy is causing the CCP code to think a value is a known > constant, instead of a VARYING: > > if (flag_tree_bit_ccp > && ((is_constant && TREE_CODE (val.value) == INTEGER_CST) > || !is_constant) > && gimple_get_lhs (stmt) > && TREE_CODE (gimple_get_lhs (stmt)) == SSA_NAME) > { > tree lhs = gimple_get_lhs (stmt); > wide_int nonzero_bits = get_nonzero_bits (lhs); > if (nonzero_bits != -1) > { > if (!is_constant) > ... > > nonzero_bits is no longer equal to -1, so we think we have a known value. > > IMO, a precision of 0 makes no sense. Perhaps we should even hard fail in > get_nonzero_bits for this case, and have all callers fix their nonsense. Yeah, we do assert we are not passed a POINTER_TYPE but in reality in addition to that we only may look at INTEGRAL_TYPE_P types. So -- assert that in *_range_info and *nonzero_bits and fix callers. Oh, I think nonzero_bits can handle POINTER_TYPEs just fine. I suppose the idea was to make nonzero_bits foolproof. And -1 being sign-extended should be fine... unless precision is 0 ;) So, in nonzero_bits use TYPE_PRECISION only for INTEGRAL_TYPE_P and POINTER_TYPE_P but for other types use TYPE_SIZE (or some arbitrary nonzero precision? BITS_PER_UNIT?).