Mark Mitchell <[EMAIL PROTECTED]> writes: > let's disable the assumption about signed overflow not wrapping for > VRP, but leave it in place for loop analysis.
As far as I know this will work for all the wrapv-assuming code that we've found, so it should be an improvement. Thanks to all for helping to think it through. > it sounds like that would eliminate most of the problem. Certainly, > making -INT_MIN evaluate to INT_MIN, when expressed like that, is an > easy thing to do; that's just a guarantee about constant folding. Well, no, just to clarify: the GCC code in question actually computed "- x", and relied on the fact that the result was INT_MIN if x (an unknown integer) happened to be INT_MIN. Also, now that I'm thinking about it, some the Unix v7 atoi() implementation relied on "x + 8" evaluating to INT_MIN when x happened to be (INT_MAX - 7). These are the usual kind of assumptions in this area. > I don't even necessarily think we need to change our user documentation. Here I'd like to demur, since I think it's useful to document something that users can rely on. I'm not asking that we document every possible wrapv-assuming code that happens to work. I'm only asking for enough so that users can easily write code that tests for signed integer overflow, or to compute sums, products, etc. that would apply if -fwrapv were in effect.