On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 11/8/18 8:59 AM, Richard Biener wrote: > > On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez <al...@redhat.com> wrote: > >> > >> get/set_range_info() currently returns the extremes of a range. I have > >> implemented overloaded variants that return a proper range. In the > >> future we should use actual ranges throughout, and not depend on range > >> extremes, as depending on this behavior could causes us to lose precision. > >> > >> I am also including changes to size_must_be_zero_p() to show how we > >> should be using the range API, as opposed to performing error prone > >> ad-hoc calculations on ranges and anti-ranges. > > > > Yeah, I've been talking this all along but not being heard... > > My girlfriend says I don't listen. It could be related. > > >> Martin, I'm not saying your code is wrong. There are numerous other > >> places in the compiler where we manipulate ranges/anti-ranges directly, > >> all of which should be adapted in the future. Everywhere there is a > >> mention of VR_RANGE/VR_ANTI_RANGE in the compiler is suspect. We should > >> ideally be using intersect/union/may_contain_p/null_p, etc. > > > > null_p is a bad name btw, I just confused it with empty_p ... (which we have > > as undefined_p). contains_only_zero_p would be less confusing. > > Yes, a horrible name. I noticed so as I debugged precisely this bit. > How about zero_p?
Probably the same ambiguous connotation? But yes, way better than null_p. Richard. > Aldy
