On Thu, May 18, 2017 at 5:08 PM, Robin Dapp <rd...@linux.vnet.ibm.com> wrote: >> Any reason to expose tree-vrp.c internal interface here? The function >> looks quite expensive. Overflow check can be done by get_range_info >> and simple wi::cmp calls. Existing code like in >> tree-ssa-loop-niters.c already does that. Also could you avoid using >> comma expressions in condition please? It only makes the code harder >> to be read. > > I tried get_range_info () as well and got a FAIL in > gcc.c-torture/execute/bitfld-5.c. > where get_range_info () returns a VR_RANGE but extract...() gives > VR_VARYING. The test case relies on not simplifying, i.e. would expect > a VR_VARYING here but I didn't look into it more. I can guess what is happening here. It's a 40 bits unsigned long long field, (s.b-8) will be like: _1 = s.b _2 = _1 + 0xfffffffff8 Also get_range_info returns value range [0, 0xFFFFFFFFFF] for _1. You'd need to check if _1(with range [0, 0xFFFFFFFFFF]) + 0xfffffffff8 overflows against precision of the bit-field which is 40 bits precision. The failure might because overflowness is checked against unsigned long long's precision which is 64 bits.
> > Also, is there a possibility to know if there was an "ok" overflow or > not from get_range_info ()'s output? Would I have to compare the result > with the involved variable's range? I think you have to check it manually against max/min value of that type precision. Thanks, bin > > Regards > Robin >
