On Fri, May 19, 2017 at 12:13 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: > On Fri, May 19, 2017 at 11:09 AM, Robin Dapp <rd...@linux.vnet.ibm.com> wrote: >>> 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. >> >> Currently, extract_... () does that all that for me, is it really too >> expensive to call? I guess, using get_range_info first and calling >> extract when get_range_info returns a VR_RANGE is not really a favorable >> thing to do either? :) > Not only the cost, we should avoid introducing more interfaces while > old ones can do the work. Anyway, it's Richard's call here.
Using get_range_info and wi:: is prefered, I didn't look into the issue you are running into but wi:: do have proper bit-precision tracking. Maybe the overflow checks are not implemented correctly there though. Richard. > Thanks, > bin >> >> Regards >> Robin >>
