------- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 09:59 ------- (In reply to comment #3) > (In reply to comment #1) > > then it can only be postive > > Plausible, but I don't think so.
Again signed type overflow is undefined by the C standard so it can do anything. So in this case, we optimize out the n == 0 compare. > > The executed code displays a negative number after about > 64 iterations, then displays about thirty zeros. > > There is one set bit in local variable n, and it gets moved up > once per iteration. > > At the last but one iteration, n goes negative, because > the sign bit is set. Again once you have a signed overflow, then the behavior is undefined which is why the n == 0 compare is optimized to true. > > Then n goes to zero. > > Then the test for n == 0 mysteriously fails in the optimiser. Yes by the VRP because n can never be negative because again signed type overflow is undefined. If we do INT_MAX*2, we could still get INT_MAX as allowed by the C standard. > I'd be interested to see what execution you get on your machine > for this code. I already know what it does. Use -fwrapv or unsigned types if you want something which is defined for overflow. -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245