https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #12)
> (In reply to Richard Biener from comment #11)
> > So we somehow have recorded a non-null global range for a5_16:
[...]
>
> THe code in dom_opt_dom_walker::set_global_ranges_from_unreachable_edges:
>
> FOR_EACH_GORI_EXPORT_NAME (m_ranger->gori_ssa (), pred_e->src, name)
> if (all_uses_feed_or_dominated_by_stmt (name, stmt)
> // The condition must post-dominate the definition point.
> && (SSA_NAME_IS_DEFAULT_DEF (name)
> || (gimple_bb (SSA_NAME_DEF_STMT (name))
> == pred_e->src)))
> {
> value_range r (TREE_TYPE (name));
>
> if (m_ranger->range_on_edge (r, pred_e, name)
> && !r.varying_p ()
> && !r.undefined_p ())
> {
> set_range_info (name, r);
> maybe_set_nonzero_bits (pred_e, name);
> }
> }
>
> SO I believe it is true that a5_16 is in fact [1, +INF] for all uses within
> the function.
> I guess the problem is that in dom2 the order is
> if (a4_14 == 0) return if (a4_14 == a5_16)
> IN which case it is true that a5_16 is globally [1, +INF] for all uses.
I think this logic pre-dates the ability to have relations involved. Because
we effectively have if (a5_16 == 0) return; if (a5_16 == 0) unreachable ();
where you of course cannot make a5_16 != 0 globally. But the
all_uses_feed_or_dominated_by_stmt does not consider equal-related stmt uses.
Do we know sth like "no (in-)equality relations with another name"? I think
we'd have to assert this here as well.
The alternative would be to make sure to reset flow-sensitive info on
the condition. But it's only the above "all-uses-dominate stmt"
speciality that can ever get us into problems. It was of course (IIRC)
important to do this because eliding the __builtin_unreachable (what
DOM does not do in this case!) removes some context sensitivity of the
range as there's no SSA def to root a range on.
