> 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. 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? Regards Robin
