On 09/04/2018 10:20 AM, Richard Biener wrote:
On Tue, Sep 4, 2018 at 4:12 PM Aldy Hernandez <al...@redhat.com> wrote:
I honestly don't remember exactly but I suppose precision mismatched somehow. Your code was OK with not using widest_ints.
Ah, this got lost in the noise. Sorry. Will commit the original patch.
Yes, but for truncation of ~[0, 5] from say int to short it's not correct to make the result ~[0, 5], is it? At least the original code dropped that to VARYING. For the same reason truncating [3, 765] from short to unsigned char isn't [3, 253]. But maybe I'm missing something.Correct, but in that case we will realize that in wide_int_range_convert and refuse to do the conversion: /* If the conversion is not truncating we can convert the min and max values and canonicalize the resulting range. Otherwise we can do the conversion if the size of the range is less than what the precision of the target type can represent. */ if (outer_prec >= inner_prec || wi::rshift (wi::sub (vr0_max, vr0_min), wi::uhwi (outer_prec, inner_prec), inner_sign) == 0)so you say the check is also sufficient for all anti-ranges? I see the current VRP code does canonicalization to ranges before running into the CONVERT_EXPR_CODE case.
Yes. exactract_range_into_wide_ints() will do the right thing. Thanks again. Aldy
