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... > 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. > OK pending another round of tests? (As I had tested this patch along > with a whole slew of other upcoming changes ;-)). OK. Richard. > > Aldy
